Hi Anil, If you have GroupBy condition in query and all "rows" that belong to one group are collocated with affinity key, then group is collocated and you can use "collocate = true" option to allow Ignite apply optimization. Otherwise, it is not a collocated grouping and GroupBy should be apply on reduce stage; You will get wrong result with "collocate = true" option.
Map response is always returned to node that initiate query (reduce node), reduce stage will apply anyway. On Tue, Feb 7, 2017 at 1:37 PM, Anil <anilk...@gmail.com> wrote: > Hi Andrey, > > thanks for response and little confused. > > I hope "group" is the entries of two (or more) caches which are collocated > with affinity key. please correct if i am wrong. > > "For example: In this case, we can make grouping and apply Having > condition on map stage, that > results in reducing network traffic." - *Agree. no aggregation in reduce > and apply pagination and return to client ? or just return map response to > client ?* > > Thanks. > > > On 7 February 2017 at 14:55, Andrey Mashenkov <andrey.mashen...@gmail.com> > wrote: > >> Hi Anil, >> >> Group by queries with collocate = true will be correct if: >> for every group there is only partition that contains all data of this >> group. >> Ignite does not know if group data is collocated for a query, so with >> this option we can give a hint to Ignite. >> >> For example: In this case, we can make grouping and apply Having >> condition on map stage, that >> results in reducing network traffic. >> >> For non-collocated groups we can't apply Having on map stage as we have >> only part of data at this time. >> So, in this case with collocate = true we can get wrong results. >> >> >> >> On Tue, Feb 7, 2017 at 6:29 AM, Anil <anilk...@gmail.com> wrote: >> >>> Hi, >>> >>> May I know what do you mean by "When used incorrectly" ? >>> >>> group by queries with collocate = true is not incorrect usage or i >>> misunderstood this ? >>> >>> Thanks. >>> >>> On 7 February 2017 at 01:26, vkulichenko <valentin.kuliche...@gmail.com> >>> wrote: >>> >>>> Well, I would agree that the flag is confusing, but your understanding >>>> is not >>>> correct. When used incorrectly, this flag does breaks query result >>>> because >>>> it forces Ignite to change execution plan to more optimal. This >>>> optimization >>>> doesn't always work though (that's actually the reason why it's >>>> configurable). >>>> >>>> -Val >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://apache-ignite-users.705 >>>> 18.x6.nabble.com/NOT-IN-in-ignite-tp9861p10458.html >>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com. >>>> >>> >>> >> >> >> -- >> Best regards, >> Andrey V. Mashenkov >> > > -- Best regards, Andrey V. Mashenkov
