In particular, there's a not implausible optimisation opportunity that could alter things... In the general case, the execution of "GROUP BY a, b" will "naturally" involve a sort on "a, b" to bring all the "to be grouped" entries together. In the OP's case, there's a primary key on "a, b" so there can only be one entry per group. As I understand it, it would therefore be valid to just scan the table and emit the "groups" (of size one) in whatever order they happen to be stored. Graham. Sent from my Samsung Galaxy S7 - powered by Three -------- Original message --------From: Simon Slavin <slav...@bigfraud.org> Date: 17/09/2018 09:09 (GMT+00:00) To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Subject: Re: [sqlite] [EXTERNAL] The "natural" order of the query results. On 17 Sep 2018, at 7:19am, John Found <johnfo...@asm32.info> wrote:
> Yes, of course, but you forgot about INDEXED BY clause. It will force using > particular index. So, the query planner will always use exactly this index, > regardless of how optimal it is and > as long as GROUP BY and ORDER BY are working the same way, this gives some > guarantee for the ordering without ORDER BY clause. No. Just because it works now doesn't mean it will continue to work that way in the future, unless the documentation says so. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
