On 2011-12-14 19:48, Tom Lane wrote:
> 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.
I can see that it is hard to generalize, but in the tsvector case the
we are indeed not capable of reconstructing the row since the
positions are not stored in the index, the actual lookup is not a
lossy and I'm fairly sure (based on experience) that pg dont
revisit heap-tuples for checking (only for visibillity).
--
Jesper
--
Jesper
