Re: SP-GiST versus index-only scans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jesper Krogh <jesper(at)krogh(dot)cc>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: SP-GiST versus index-only scans
Date: 2011-12-14 18:48:22
Message-ID: 11623.1323888502@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jesper Krogh <jesper(at)krogh(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-12-14 19:49:11 Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64
Previous Message Jesper Krogh 2011-12-14 18:29:24 Re: SP-GiST versus index-only scans