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

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Allow GiST distance function to return merely a lower-bound.
Date
Msg-id 2140.1432412868@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Allow GiST distance function to return merely a lower-bound.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Next
From: Tom Lane
Date:
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously