From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Eivind Kvedalen <eivindkv(at)ifi(dot)uio(dot)no> |
Cc: | Michael A Nachbaur <mike(at)nachbaur(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: "Join" on delimeter aggregate query |
Date: | 2003-06-09 01:05:55 |
Message-ID: | 3649.1055120755@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Eivind Kvedalen <eivindkv(at)ifi(dot)uio(dot)no> writes:
> SELECT a, concat(b) FROM (SELECT a,b FROM test ORDER BY a,b) T GROUP BY a;
> The ORDER BY is included to sort the rows before they are aggregated. I'm
> not sure that this guarantees that they actually will be sorted, but maybe
> some of the postgresql hackers can confirm/deny this?
This technique will work reliably as of 7.4, but it's not reliable
in existing releases. The GROUP BY will do its own sort on A, and
unless qsort() is stable on your machine (which it's not, in most
implementations) the secondary ordering by B will be destroyed.
The fix in 7.4 simply makes the planner smart enough to notice that
the sub-select's output is already adequately sorted for grouping
by A.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eivind Kvedalen | 2003-06-09 08:35:10 | Re: "Join" on delimeter aggregate query |
Previous Message | Joe Conway | 2003-06-08 22:33:48 | Re: Using a RETURN NEXT |