Re: COUNT(*) and index-only scans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COUNT(*) and index-only scans
Date
Msg-id 14030.1318433514@sss.pgh.pa.us
Whole thread Raw
In response to Re: COUNT(*) and index-only scans  (Aidan Van Dyk <aidan@highrise.ca>)
List pgsql-hackers
Aidan Van Dyk <aidan@highrise.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


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: COUNT(*) and index-only scans
Next
From: Robert Haas
Date:
Subject: Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME