Thread: Re: [COMMITTERS] pgsql: Allow GiST distance function to return merely a lower-bound.

Heikki Linnakangas <heikki.linnakangas@iki.fi> writes:
> Allow GiST distance function to return merely a lower-bound.

I wondered how come this patch did not touch nodeIndexonlyscan.c.

After some investigation, it seems the only reason that this patch even
appears to work is that none of the built-in or contrib opclasses support
both lossy ordering operators and GIST fetch functions.  Otherwise we
would do an index-only scan and the executor would simply ignore the
recheck flag.

I doubt we can ship this in this state; even if the core code doesn't
exercise the problematic combination, surely third-party opclasses
will want to?

I thought about hacking the planner to not select index-only scans,
but there's no way for it to know whether the opclass might return
recheck = true at runtime.  I think the only real fix is to actually
propagate all the changes in nodeIndexscan.c into nodeIndexonlyscan.c.
Testing it would be problematic without a suitable opclass, though :-(

A short-term hack might be to throw a "not implemented" error in
nodeIndexonlyscan.c if it sees the distance-recheck flag set.
        regards, tom lane

I wrote:
> Heikki Linnakangas <heikki.linnakangas@iki.fi> writes:
>> Allow GiST distance function to return merely a lower-bound.

> I wondered how come this patch did not touch nodeIndexonlyscan.c.

> After some investigation, it seems the only reason that this patch even
> appears to work is that none of the built-in or contrib opclasses support
> both lossy ordering operators and GIST fetch functions.  Otherwise we
> would do an index-only scan and the executor would simply ignore the
> recheck flag.

> I doubt we can ship this in this state; even if the core code doesn't
> exercise the problematic combination, surely third-party opclasses
> will want to?

On further thought, maybe it's OK: we'd only be using an index-only scan
if the index can return the exact value of the indexed column (as the
circle and polygon GIST opclasses cannot).  If it can do that, then it
should be able to compute exact distances too --- worst case, it could
reconstitute the column value and apply the distance operator itself.
So maybe we don't need to add a pile of code for that.

We do need a not-implemented error check though, so I added one.
        regards, tom lane