Dmitriy, Yes, you're right. Moreover, it looks like a good practice to combine caches that will be used for collocated JOINs in one group since it reduces overall overhead.
I think it's not a problem to add this restriction to the SQL JOIN level if we will decide to use this solution. Evgenii 2017-08-09 17:07 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > On Wed, Aug 9, 2017 at 6:28 AM, ezhuravl <e.zhuravlev...@gmail.com> wrote: > > > Folks, > > > > I've started working on a https://issues.apache.org/ > > jira/browse/IGNITE-5836 > > ticket and found that the recently added feature with cacheGroups doing > > pretty much the same that was described in this issue. CacheGroup > > guarantees > > that all caches within a group have same assignments since they share a > > single underlying 'physical' cache. > > > > > I think we can return FairAffinityFunction and add information to its > > Javadoc that all caches with same AffinityFunction and NodeFilter should > be > > combined in cache group to avoid a problem with inconsistent previous > > assignments. > > > > What do you guys think? > > > > Are you suggesting that we can only reuse the same FairAffinityFunction > across the logical caches within the same group? This would mean that > caches from the different groups cannot participate in JOINs or collocated > compute. > > I think I like the idea, however, we need to make sure that we enforce this > restriction, at least at the SQL JOIN level. > > Alexey G, Val, would be nice to hear your thoughts on this. > > > > > > Evgenii > > > > > > > > -- > > View this message in context: http://apache-ignite- > > developers.2346864.n4.nabble.com/Resurrect-FairAffinityFunction- > > tp19987p20669.html > > Sent from the Apache Ignite Developers mailing list archive at > Nabble.com. > > >
