From: | Zeugswetter Andreas DBT <Andreas(dot)Zeugswetter(at)telecom(dot)at> |
---|---|
To: | "'pgsql-hackers(at)hub(dot)org'" <pgsql-hackers(at)hub(dot)org> |
Subject: | Re: [HACKERS] No: implied sort with group by |
Date: | 1998-01-28 08:36:17 |
Message-ID: | 219F68D65015D011A8E000006F8590C6010A51AF@sdexcsrv1.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Shapiro | 1998-01-28 08:37:29 | Re: [HACKERS] Domain Problem? |
Previous Message | Thomas G. Lockhart | 1998-01-28 07:47:21 | Re: [HACKERS] Re: Re: [PORTS] the 'money' type |