Robert Haas <robertmh...@gmail.com> writes: > On Fri, Oct 21, 2011 at 1:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I don't know why you'd imagine that touching an index is free, or even >> cheap, CPU-wise. The whole point of the index-only optimization is to >> avoid I/O. When you try it on a case where there's no I/O to be saved, >> *and* no shared-buffers contention to be avoided, there's no way it's >> going to be a win.
> Well, call me naive, but I would have thought touching six times less > data would make the operation run faster, not slower. It's not "touching six times less data". It's touching the exact same number of tuples either way, just index tuples in one case and heap tuples in the other. You've arranged the test case so that all these tuples are in shared buffers already, so there's no data movement to be avoided. What this test case proves is that btree's overhead per index tuple touched is significantly more than the cost of the fastest path through HeapTupleSatisfiesMVCC, which I don't find surprising considering how much sweat has been expended on that code path over the years. (It may well be that it's not even btree at fault but the per-tuple visits to the visibility map ... did you do any oprofiling yet?) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers