X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 8BD3F313471 for ; Tue, 10 Jun 2003 04:43:01 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 22679-03 for ; Tue, 10 Jun 2003 01:42:50 -0300 (ADT) Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by svr1.postgresql.org (Postfix) with ESMTP id 89B9730FC84 for ; Mon, 9 Jun 2003 08:35:13 +0000 (GMT) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19PI7V-0002l4-00; Mon, 9 Jun 2003 10:35:13 +0200 Received: from [129.240.130.16] (helo=pat.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.14) id 19PI7T-000125-Me; Mon, 09 Jun 2003 10:35:11 +0200 Received: from fimm.ifi.uio.no ([129.240.65.205]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19PI7T-0002kz-00; Mon, 9 Jun 2003 10:35:11 +0200 Received: from localhost (eivindkv@localhost) by fimm.ifi.uio.no ; Mon, 9 Jun 2003 10:35:10 +0200 (MEST) Date: Mon, 9 Jun 2003 10:35:10 +0200 (MEST) From: Eivind Kvedalen To: Tom Lane Cc: pgsql-sql@postgresql.org Subject: Re: "Join" on delimeter aggregate query In-Reply-To: <3649.1055120755@sss.pgh.pa.us> Message-ID: References: <200306061003.29430.mike@nachbaur.com> <3649.1055120755@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found X-Archive-Number: 200306/68 X-Sequence-Number: 13826 On Sun, 8 Jun 2003, Tom Lane wrote: > Eivind Kvedalen 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 ma= ybe > > 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. Ok. What I actually had in mind was whether the optimizer would remove the ORDER BY clause completely or not, as it isn't used in the top-level SELECT query, and SQL doesn't in general guarantee ordered rows back unless there's an ORDER BY in the top-level SELECT (I haven't read the SQL standard, so I might very well be wrong here). The GROUP BY sorts on A to do the grouping correctly, right? (That is, removing the duplicates from A) (Now, thinking more about this, removing the ORDER BY in the optimizer as I suggested above would effectively remove the ORDER BY in created views, right?) Eivind --=20 | Mail: eivindkv@ifi.uio.no | Lazy on IRC | HP: www.stud.ifi.uio.no/~eivindkv | "Jeg skal vrenge deg med h=E5ret | Tlf: 22187123/93249534 | inn." | | -- Yang Tse Lyse