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 20:15:15 |
Message-ID: | 13122.1323893715@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:48, Tom Lane wrote:
>> 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.
> 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).
Well, the way the tsvector code handles this stuff is that it reports
the result as lossy only if the query actually poses a constraint on
position (some do, some don't). That case was actually what made us
move the determination of lossiness from plan time to execution time,
since in the case of a non-constant tsquery, there's no way for the
planner to know about it (and even with the constant case, you'd need a
helper function that doesn't exist today). But this behavior is
problematic for index-only scans because the planner can't tell whether
a query will be lossy or not, and it makes a heck of a lot bigger
difference than it used to.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-12-14 20:34:23 | Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64 |
Previous Message | Tom Lane | 2011-12-14 20:09:48 | Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64 |