From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: the big picture for index-only scans |
Date: | 2011-05-11 00:55:37 |
Message-ID: | BANLkTikiYy+OTFCUcpOVuvVNf3WFU=pSRg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 11, 2011 at 1:47 AM, Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-05-11 00:59:38 | Re: Why not install pgstattuple by default? |
Previous Message | Bruce Momjian | 2011-05-11 00:47:18 | Re: the big picture for index-only scans |