Re: visibilitymap_count() at the end of vacuum

On Mon, Dec 3, 2012 at 1:36 PM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> wrote:
> Well, may be the cost is low. But it can still run into several hundred or
> thousand pages that are read into the buffer pool again. If there is indeed
> too much churn happening, an ANALYZE will kick in which will count the bits
> anyway or the next VACUUM will correct it (though it may become out dated
> again)

Several hundred pages? Each visibility map page covers 512 MB of heap
pages. If you read "several hundred" of them, you're talking about a
relation that is over 100GB in size. If you read several thousand,
you're over a terabyte. There are probably a few people who have
PostgreSQL relations that large, but not many.

Also, if someone does have a 100GB relation, rereading 2MB of
visibility map pages at the end probably isn't a significant part of
the total cost. Even if 99.9% of the relation is all-visible and we
skip reading those parts, the visibility map reads will still be only
about 2% of the total read activity, and most of the time you won't be
that lucky.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company