Re: visibilitymap_count() at the end of vacuum

On Mon, Dec 3, 2012 at 11:50 PM, Andres Freund <andres(at)2ndquadrant(dot)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