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