Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
От | Greg Stark |
---|---|
Тема | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
Дата | |
Msg-id | BANLkTi=6RYvEVfKn8ufPEf9meGVEu=fHsQ@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 Sat, May 28, 2011 at 12:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I also found that Greg was right in thinking that it would help if we > tweaked lazy_scan_heap to not always scan the first > SKIP_PAGES_THRESHOLD-1 pages even if they were > all_visible_according_to_vm. That seemed to skew the results if those > pages weren't representative. And, for the case of a useless manual > vacuum on a completely clean table, it would cause the reltuples value > to drift when there was no reason to change it at all. You fixed the logic only for the first 32 pages which helps with the skew. But really the logic is backwards in general. Instead of counting how many missed opportunities for skipped pages we've seen in the past we should read the bits for the next 32 pages in advance and decide what to do before we read those pages. -- greg
В списке pgsql-hackers по дате отправления: