Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Дата
Msg-id BANLkTi=ONrsOoMD3rOdPjRnKPrirKE+fpg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, May 29, 2011 at 8:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Cédric Villemain <cedric.villemain.debian@gmail.com> writes:
>> 2011/5/29 Tom Lane <tgl@sss.pgh.pa.us>:
>>> OK, do you like the attached version of that logic?  (Other fragments
>>> of the patch as before.)
>
>> The idea was that remove only one page from the VACUUM will prevent
>> relfrozenxid update and reltuples (and relpages) update.
>> Now, I beleive that once we've skip at least one page thanks to
>> SKIP_PAGES_THRESHOLD, then we should be more agressive and remove as
>> many as possible pages from the VACUUM, tks to the VM.
>
> That would require proof, not just suggestion.  Skipping pages will
> defeat the OS read-ahead algorithm, and so could easily cost more than
> reading them.
>

My worry is what we have right now is also based on just assumptions
and gut feelings rather than any numbers.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Getting a bug tracker for the Postgres project
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum