gianm commented on pull request #10235: URL: https://github.com/apache/druid/pull/10235#issuecomment-668347378
> > Note: I don't think this patch has the issue from [#10233 (comment)](https://github.com/apache/druid/pull/10233#issuecomment-668173929), because unlike Scan queries, GroupBy query results are stable from run to run. (There is always an ordering, even if it's implicit.) > > Nevermind! I realized that this isn't true at the outer layer of the query. It's true when merging is happening, but not when we're going to apply the offset, because the LimitSpec might have reordered things in an unstable way if not all dimensions were provided as orderBys. I'll modify DefaultLimitSpec to use a stable sort and add some tests. OK, I just pushed a commit that stabilizes the sort, at the cost of an extra counter per element. I think this is okay, because we don't expect the limited resultset on a query like this to be very close to the amount of memory we have available. (Of course, it's possible for a user to type in a very high number, but in this case we'd do better to move the sorting off-heap.) ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
