Re: SP-GiST versus index-only scans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SP-GiST versus index-only scans
Date
Msg-id 11623.1323888502@sss.pgh.pa.us
Whole thread Raw
In response to Re: SP-GiST versus index-only scans  (Jesper Krogh <jesper@krogh.cc>)
Responses Re: SP-GiST versus index-only scans  (Jesper Krogh <jesper@krogh.cc>)
List pgsql-hackers
Jesper Krogh <jesper@krogh.cc> writes:
> On 2011-12-14 19:00, Tom Lane wrote:
>> So the problem is that we have to either disallow such opclass designs,
>> or support per-opclass rather than per-index-AM decisions about whether
>> index-only scans are possible.

> Just a quick comment, for some queries like the famous
> select count(*) from table where column @@ to_tsquery('something');
> I do think index-only-scans does make sense even on indices
> where the original tuple cannot be re-constructed. This also goes
> for gin indices as well.

I think this is somewhat wishful thinking unfortunately.  The difficulty
is that if the index isn't capable of reconstructing the original value,
then it's probably giving only an approximate (lossy) answer, which
means we'll have to visit the heap to recheck each result, which
pretty much defeats the purpose of an index-only scan.  So I can't get
excited about contorting things to support this.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jesper Krogh
Date:
Subject: Re: SP-GiST versus index-only scans
Next
From: Simon Riggs
Date:
Subject: Re: Race condition in HEAD, possibly due to PGPROC splitup