"Decibel!" <decibel@decibel.org> 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
