Re: visibilitymap_count() at the end of vacuum - Mailing list pgsql-hackers

From Robert Haas
Subject Re: visibilitymap_count() at the end of vacuum
Date
Msg-id CA+TgmoZFZgsDe0HGLzSE1m6ESjRRv=+sOnM=Prpozj0y4Y_7fg@mail.gmail.com
Whole thread Raw
In response to Re: visibilitymap_count() at the end of vacuum  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: visibilitymap_count() at the end of vacuum
List pgsql-hackers
On Mon, Dec 3, 2012 at 1:36 PM, Pavan Deolasee <pavan.deolasee@gmail.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Review: Extra Daemons / bgworker
Next
From: "Kevin Grittner"
Date:
Subject: Re: autovacuum truncate exclusive lock round two