darrenk wrote:
> postgres should then do an internal sort before grouping. In the
second
> of your examples, I take the above to mean that either row could be
> returned first.
yes (standard speak)
> In order to get that result set though, the data needs to be sorted
before
> getting to the group by node in the executor. The order of that
internal
> sort is purely arbitrary, it just has to be done.
either that or group the result set into an implicit temp table
internally.
If a compound index exists on b,c then an index path could be used
instead.
(compound btree would also be good for order by, of course yall know ;-)
An auto index path (temp index is created on the fly and dropped after
query completion)
might also be considered.
Andreas