Re: the big picture for index-only scans - Mailing list pgsql-hackers

From Greg Stark
Subject Re: the big picture for index-only scans
Date
Msg-id BANLkTikiYy+OTFCUcpOVuvVNf3WFU=pSRg@mail.gmail.com
Whole thread Raw
In response to Re: the big picture for index-only scans  (Bruce Momjian <bruce@momjian.us>)
Responses Re: the big picture for index-only scans  (Bruce Momjian <bruce@momjian.us>)
Re: the big picture for index-only scans  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, May 11, 2011 at 1:47 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Isn't speeding up COUNT(*) a sufficient case because it will not have to
> touch the heap in many cases?

Putting aside the politics questions, count(*) is an interesting case
-- it exposes some of the unanswered questions about index-only scans.

The reason "select count(*)" might win would be because we could pick
any index and do an index scan, relying on the visibility map to
optimize away the heap reads. This is only going to be a win if a
large fraction of the heap reads get optimized away.

It's going to be pretty tricky to determine in the optimizer a) which
index will be cheapest and b) what fraction of index tuples will point
to pages where the heap reference can be optimized away. The penalty
for guessing wrong if we use an index-only scan and it turns out to
have many pages that aren't all-visible would be pretty high.


-- 
greg


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: the big picture for index-only scans
Next
From: Bruce Momjian
Date:
Subject: Re: Why not install pgstattuple by default?