Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
От | Cédric Villemain |
---|---|
Тема | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
Дата | |
Msg-id | BANLkTinL6QuAm_Xf8teRZboG2Mdy3dR_vw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2011/5/29 Tom Lane <tgl@sss.pgh.pa.us>: > 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. Correct, it needs proof. Parenthesis: I did learn also that reading the first block of a file make read-ahead have its larger window from the beginning (the one that posix_fadvise_sequential set too), so remove those initial reads might be counter-productive also. But this is damn hard to benchmark because the read ahead is also influenced by memory pressure for example. From theory, 1. readahead algo is a bit smarter and can work with read-with-holes (if the holes are not larger than the read-ahead window) and 2. if holes are that large then maybe it is not so good to keep a larger read-ahead window (which keep trashing our buffer cache). -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: