| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Stark <stark(at)mit(dot)edu>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: COUNT(*) and index-only scans |
| Date: | 2011-10-12 15:31:54 |
| Message-ID: | 14030.1318433514@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> The elephant in the room is that the index-only-scan really doesn't
> save a *whole* lot if the heap pages are already in shared buffers.
> But it matters a *lot* when they heap pages are not in shared buffers
> (both ways, saving IO, or causing lots of random IO)
> Can we hope that if pages are not in shared buffers, they are not
> recently modified, so hopefully both all visible, and have the VM
> bit?set? Or does the table-based nature of vacuum mean there is no
> value there?
Hmm, that's an interesting point. If you suppose that recently-modified
pages are likely to still be in memory then it could well be that an
index-only scan is relatively cheap (i.e., not many actual disk reads)
no matter whether it hits recently-modified pages or not. So maybe the
first cut should just be to measure the overall visibility fraction and
use that at face value.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-10-12 15:32:03 | Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME |
| Previous Message | Greg Stark | 2011-10-12 15:30:00 | Re: COUNT(*) and index-only scans |