Re: [GENERAL] Backwards index scan

Is this a TODO?

---------------------------------------------------------------------------

Tom Lane wrote:
> [ reply redirected to a more appropriate list ]
> 
> Dmitry Tkach <dmitry@openratings.com> writes:
> > I am not sure if this is really a bug, but it certainly looks like one 
> > to me...
> 
> It's not a bug, but I agree that _bt_first can be inefficient if there
> are lots of matching keys.
> 
> > This is because there are *lots* (a few million) of matches for x=10, 
> > and _bt_first () scans through them *all* sequentually to get to the 
> > last one.
> > I understand that with the generic approach to operators in postgres it 
> > is, probably, not very feasible to try and teach _bt_first () to handle 
> > this situation automatically (it would need to know how to get 
> > next/previous value for every indexable type)...
> 
> I think what we'd want is variant versions of _bt_search and _bt_binsrch
> that locate the first entry greater than the specified target key,
> rather than the first entry greater than or equal to it.  Given such
> positioning, all the _bt_first cases that involve stepping over more
> than one entry could be improved to require no more than one step.
> 
> Not sure whether it'd be better to make clone versions of these
> functions, or to add a parameter to tell them which behavior is wanted.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073