Skip site navigation (1) Skip section navigation (2)

Re: best way to fetch next/prev record based on index

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: gsstark(at)mit(dot)edu, 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-28 03:45:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Tue, 27 Jul 2004, Merlin Moncure wrote:

> 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).

Given the comment on make_row_op,
   * XXX it's really wrong to generate a simple AND combination for < <=
   * > >=.  We probably need to invent a new runtime node type to handle
   * those correctly.  For the moment, though, keep on doing this ...
I'd expect it'd be accepted.

In response to


pgsql-performance by date

Next:From: Greg StarkDate: 2004-07-28 05:53:17
Subject: Re: best way to fetch next/prev record based on index
Previous:From: Stan BielskiDate: 2004-07-27 19:38:05
Subject: Optimizer refuses to hash join

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group