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

Wed, 28 Jan 1998 09:36:17 +0100
Zeugswetter Andreas DBT <Andreas.Zeugswetter@telecom.at>
Re: [HACKERS] No: implied sort with group by