"Decibel!" <[EMAIL PROTECTED]> writes: > Makes sense, and yeah, I was wondering a bit about that. I'll try to > fake it out with offset 0 later on if no one beats me to it; I do still > think we could just be seeing the effect of slogging through 200 tuples > instead of going directly to the one we want.
Of course index lookups aren't magic. You don't get to go *directly* to the one you want. You still have to slog through index tuples to find the right pointer. That means going to the index meta page, find the fast root pointer, look up that page, look at the single leaf page pointer, look up that page, and do a binary search of the 200 leaf pointers. Once you find the resulting match, look up the heap page and *then* go directly to the right tuple. So that means up to four trips to the buffer cache, trips through lwlocks, etc. And it still means up to 9 btree comparisons. Still less than 200 but it's not entirely free. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
