From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Stuart Brooks" <stuartb(at)cat(dot)co(dot)za> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Constraint on multicolumn index |
Date: | 2006-11-10 15:07:44 |
Message-ID: | 20924.1163171264@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Stuart Brooks" <stuartb(at)cat(dot)co(dot)za> writes:
> 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
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Travis Whitton | 2006-11-10 15:23:33 | Wildcard LIKE and Sub-select |
Previous Message | A. Kretschmer | 2006-11-10 14:44:58 | Re: Between and miliseconds (timestamps) |