Re: visibilitymap_count() at the end of vacuum

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: visibilitymap_count() at the end of vacuum
Дата
Msg-id CABOikdMBLETtyOZFJJDjRBjaehusnv-ioRUvMLh7Sgna_0GxcA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: visibilitymap_count() at the end of vacuum  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: visibilitymap_count() at the end of vacuum
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: visibilitymap_count() at the end of vacuum
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Visibility map page pinned for too long ?