Re: SeqScan costs

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Decibel!" <decibel(at)decibel(dot)org>
Cc: "Andrew Gierth" <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SeqScan costs
Date: 2008-08-14 00:01:29
Message-ID: 877iakpiqu.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Decibel!" <decibel(at)decibel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-08-14 00:31:59 WIP: patch to create explicit support for semi and anti joins
Previous Message Heikki Linnakangas 2008-08-13 21:58:48 Re: gsoc, oprrest function for text search take 2