Re: best way to fetch next/prev record based on index - Mailing list pgsql-performance

From Tom Lane
Subject Re: best way to fetch next/prev record based on index
Date
Msg-id 814.1091056266@sss.pgh.pa.us
Whole thread Raw
In response to Re: best way to fetch next/prev record based on index  (Greg Stark <gsstark@mit.edu>)
List pgsql-performance
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> One thing I did not like about your first pass is that it makes
>> unsupportable assumptions about there being a semantic relationship
>> between operators named, say, '<' and '<='.

> In that case though, it seems even the existing code is insufficient.

Well, yeah, we know the existing code is broken ;-)

> Instead of testing whether the operator with strcmp against "=" and
> "<>" it should perhaps be looking for an operator class and the
> strategy number for the operator and its negator.

Probably.  You can find some relevant code in indxpath.c in the stuff
that tries to determine whether partial indexes are relevant.

I think that the ideal behavior is that we not look directly at the
operator name at all.  For example it's not too unreasonable to want
to write (a,b) ~<~ (c,d) if you have an index that uses those
non-locale-aware operators.  We should find the operator that matches
the name and input arguments, and then try to make sense of the operator
semantics by matching it to btree opclasses.

Note that it's possible to find multiple matches, for example if someone
has installed a "reverse sort" opclass.  I think we would want to prefer
a match in the datatype's default opclass, if there is one, but
otherwise we can probably follow the lead of the existing code and
assume that any match is equally good.

            regards, tom lane

pgsql-performance by date:

Previous
From: Greg Stark
Date:
Subject: Re: best way to fetch next/prev record based on index
Next
From: Stan Bielski
Date:
Subject: Optimizer refuses to hash join