[Tom Lane <tgl@sss.pgh.pa.us>]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers