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

From: Greg Stark <gsstark(at)mit(dot)edu>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>, "Greg Stark" <gsstark(at)mit(dot)edu>, "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-29 17:57:55
Message-ID: 877jsmr90c.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:

> Well, if and when the rowtype comparison can be made to work over multi
> part keys (and the optimizer is made to do tricks there), postgres can
> be made to give much better generalized ISAM access. In the meantime,
> I'll just troubleshoot specific cases via application specific behavior
> as they come up. In any case, many thanks to Greg and Tom for taking
> the time to pick this apart.

Well I'm not sure whether you caught it, but Tom did come up with a
work-around that works with the current infrastructure if all the columns
involved are the same datatype.

You can create a regular btree index on the expression array[a,b,c] and then
do your lookup using array[a,b,c] > array[a1,b1,c1].

This will only work in 7.4, not previous releases, for several reasons.

--
greg

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2004-07-29 18:23:15 Re: best way to fetch next/prev record based on index
Previous Message Tom Lane 2004-07-29 17:06:26 Re: Optimizer refuses to hash join