From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Allow GiST distance function to return merely a lower-bound. |
Date: | 2015-05-23 20:27:48 |
Message-ID: | 2140.1432412868@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
I wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-05-24 01:09:07 | pgsql: Improve pgindent instructions regarding Perl backup files |
Previous Message | Tom Lane | 2015-05-23 20:24:35 | pgsql: Add error check for lossy distance functions in index-only scans |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-05-23 20:33:29 | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Previous Message | Christoph Berg | 2015-05-23 20:20:43 | Re: fsync-pgdata-on-recovery tries to write to more files than previously |