On 3 December 2012 18:20, Andres Freund <and...@2ndquadrant.com> wrote: > Hi, > > On 2012-12-03 23:44:36 +0530, Pavan Deolasee wrote: >> I wonder if we really need to make another pass over the entire visibility >> map to count the number of all-visible pages at the end of the vacuum. The >> code that I'm looking at is in src/backend/commands/vacuumlazy.c: >> >> 247 new_rel_allvisible = visibilitymap_count(onerel); >> 248 if (new_rel_allvisible > new_rel_pages) >> 249 new_rel_allvisible = new_rel_pages; >> >> We would have just scanned every bit of the visibility map and can remember >> information about the number of all-visible pages in vacrelstats, just like >> many other statistical information that we track and update the end of the >> vacuum. Sure, there might be some more updates to the VM, especially a few >> bits may get cleared while we are vacuuming the table, but that can happen >> even while we are recounting at the end. AFAICS we can deal with that much >> staleness of the data. > > 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. > > Why change it?
There's another reason for doing it this way: if VACUUM sets everything as all visible, but during the VACUUM that state is quickly reset by others, it would be a mistake not to allow for that. We want a realistic value not a best possible case. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
