Re: visibilitymap_count() at the end of vacuum

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: visibilitymap_count() at the end of vacuum
Дата
Msg-id CA+TgmoZFZgsDe0HGLzSE1m6ESjRRv=+sOnM=Prpozj0y4Y_7fg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: visibilitymap_count() at the end of vacuum  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Ответы Re: visibilitymap_count() at the end of vacuum
Список pgsql-hackers
On Mon, Dec 3, 2012 at 1:36 PM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
> 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)

Several hundred pages?  Each visibility map page covers 512 MB of heap
pages.  If you read "several hundred" of them, you're talking about a
relation that is over 100GB in size.   If you read several thousand,
you're over a terabyte.  There are probably a few people who have
PostgreSQL relations that large, but not many.

Also, if someone does have a 100GB relation, rereading 2MB of
visibility map pages at the end probably isn't a significant part of
the total cost.  Even if 99.9% of the relation is all-visible and we
skip reading those parts, the visibility map reads will still be only
about 2% of the total read activity, and most of the time you won't be
that lucky.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Review: Extra Daemons / bgworker
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: autovacuum truncate exclusive lock round two