3. I did not understand your answer in point 3. I must join by userId to get the correct data. Are you saying that (c1.affinityId = c2.affinityId) condition should be included in on clause?
If I rewrite SQL as follows, will it work? Select * from cache1 c1 join cache2 c2 on ( c1.userId = c2.userId and and c1.affinityId = c2.affinityId) Where c1.affinityId = ? Can you please explain how ignite breaks and parse and executes this SQL internally? I will also try to spend some time to debug into ingite code to understand this. My colocation strategy as follows: I have around 20 caches. These caches contains subscription's data. I have around 5000 subscriptions. Affinity key for all 20 caches in "subscriptionId". This is done to make sure that data in all 20 caches which belongs to same the subscriptionId will landup on same node. Although this leaves my cluster unbalanced as data is not distributed equally. On Wed, Aug 29, 2018, 3:21 AM vkulichenko <[email protected]> wrote: > Prasad, > > 1. Yes, you will always see it in the execution plan because there are > always two stages. Of course, if only one server node participates in the > execution, the reduce stage is effectively no-op. > > 2. Yes, you need to put the annotation to make sure you can access it from > queries. I would recommend you to treat it in the same way as any other SQL > field. > > 3. The issue here is that you do not join by affinity key, but by user ID. > This is a non-collocated join, so it can't be executed on a single node in > the first place. I believe you should revisit your collocation strategy > here. > > 4. The fact that it exists does not mean it would be used. I think you > should fix the point #3 above before diving into further optimizations. > > -Val > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
