Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id C84699FB252 for ; Tue, 14 Nov 2006 08:56:04 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 50626-03-2 for ; Tue, 14 Nov 2006 08:55:57 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from cat.co.za (ftp.cat.co.za [196.33.33.51]) by postgresql.org (Postfix) with SMTP id BC7239FB24B for ; Tue, 14 Nov 2006 08:55:54 -0400 (AST) Received: (qmail 16855 invoked by uid 1002); 14 Nov 2006 13:04:32 -0000 Received: from stuartb@cat.co.za by mail.cat.co.za by uid 807 with qmail-scanner-1.21 (clamscan: 0.70. Clear:RC:1(196.33.33.52):. Processed in 11.684361 secs); 14 Nov 2006 13:04:32 -0000 Received: from unknown (HELO STU95) (196.33.33.52) by 0 with SMTP; 14 Nov 2006 13:04:20 -0000 Message-ID: <025a01c707eb$83a1b370$cc22a8c0@STU95> From: "Stuart Brooks" To: Cc: "Tom Lane" References: <021e01c704b1$ed75eec0$cc22a8c0@STU95> <20924.1163171264@sss.pgh.pa.us> Subject: Re: Constraint on multicolumn index Date: Tue, 14 Nov 2006 14:50:49 +0200 Organization: Intervid Technologies MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/147 X-Sequence-Number: 26799 > > But if I want the next item following t=(a=10,b=100,c=1000): > > > select * from T > > where (a=10 AND b=100 AND c>1000) OR (a=10 AND b>100) OR (a>10) > > order by a,b,c; > > The correct way to handle this is to use a SQL-spec row comparison: > > where (a,b,c) > (10,100,1000) > > Unfortunately, that syntax does not work per-spec in any existing > Postgres release. It will work properly (and use the index) in > PG 8.2, for what that's worth. > > Not sure if there's any reasonable workaround in PG <= 8.1. > You might want to check this old thread: > http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php > (note that none of the first few responses got the point :-() Also > http://archives.postgresql.org/pgsql-hackers/2006-02/msg00209.php Thanks for the response. PG 8.2 looks like a good option when it is finalized (I see it is beta 3 so shouldn't be too long should it?), but I also need to have a closer look at the row constructor - this is a new one for me as I have been using MySQL up til now. The best solution I could come up with for my problem was to do a union - something like: (SELECT * from T WHERE (a=10 AND b=100 AND c>1000) ORDER BY a,b,c LIMIT 10) UNION (SELECT * from T WHERE (a=10 AND b>100) ORDER BY a,b,c LIMIT 10) UNION (SELECT * from T WHERE (a>10) ORDER BY a,b,c LIMIT 10) ORDER BY a,b,c LIMIT 10; which would use an index for each of the selects and then have to merge, sort and limit the results. This seemed to work although it gets clumsy if there are a whole lot of extra criteria. Thanks again for the help, Stuart