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

From Pavan Deolasee
Subject Re: visibilitymap_count() at the end of vacuum
Date
Msg-id CABOikdMBLETtyOZFJJDjRBjaehusnv-ioRUvMLh7Sgna_0GxcA@mail.gmail.com
Whole thread Raw
In response to Re: visibilitymap_count() at the end of vacuum  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: visibilitymap_count() at the end of vacuum
List pgsql-hackers


On Mon, Dec 3, 2012 at 11:50 PM, Andres Freund <andres@2ndquadrant.com> wrote:


A full-table vacuum can take a *long* (as in days) time, so I think
recounting makes sense. And normally the cost is pretty small, so I
don't see a problem in this.


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)
 
Why change it?


Why not ? As I said, we would have just counted the bits and will be doing it again which looks overkill unless someone really wants to argue that the staleness of the data is going to cause the planner to really start producing way too bad plans. But note that we have lived with the staleness of reltuples and relpages for so long. So I don't see why relallvisible needs any special treatment, just because its relatively easy to recount them.

Thanks,
Pavan


--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: visibilitymap_count() at the end of vacuum
Next
From: Simon Riggs
Date:
Subject: Re: Visibility map page pinned for too long ?