| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| 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 01:40:55 |
| Message-ID: | 201105110140.p4B1etP22085@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark wrote:
> 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
I assume the smallest non-partial index would be the cheapest index.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-05-11 02:20:16 | PGC_S_DEFAULT is inadequate |
| Previous Message | Bruce Momjian | 2011-05-11 01:34:29 | Re: the big picture for index-only scans |