Re: visibilitymap_count() at the end of vacuum
От | Andres Freund |
---|---|
Тема | Re: visibilitymap_count() at the end of vacuum |
Дата | |
Msg-id | 20121203182020.GA16057@awork2.anarazel.de обсуждение исходный текст |
Ответ на | visibilitymap_count() at the end of vacuum (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Ответы |
Re: visibilitymap_count() at the end of vacuum
Re: visibilitymap_count() at the end of vacuum |
Список | pgsql-hackers |
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? Andres --Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: