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
|
Список | 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 по дате отправления: