From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | <gsstark(at)mit(dot)edu> |
Cc: | <pgsql-performance(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: best way to fetch next/prev record based on index |
Date: | 2004-07-27 19:20:49 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB34101AEFF@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Greg Stark wrote:
> > > do it for multi-column keys. It seems it would be nice if some
syntax
> > > similar to (a,b,c) > (a1,b1,c1) worked for this.
> Hum. It would seem my intuition matches the SQL92 spec and Postgres
gets
> this
> wrong.
[...]
> Even if Postgres did this right I'm not sure that would solve your
index
> woes.
> I imagine the first thing Postgres would do is rewrite it into regular
> scalar
> expressions. Ideally the optimizer should be capable of then deducing
from
> the
> scalar expressions that an index scan would be useful.
Wow. For once, the standard is my friend. Well, what has to be done?
:) Does pg do it the way it does for a reason? From the outside it
seems like the planner would have an easier job if it can make a field
by field comparison.
Would a patch introducing the correct behavior (per the standard) be
accepted? It seems pretty complicated (not to mention the planner
issues).
Merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Stan Bielski | 2004-07-27 19:38:05 | Optimizer refuses to hash join |
Previous Message | Greg Stark | 2004-07-27 18:38:48 | Re: best way to fetch next/prev record based on index |