Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Date
Msg-id BANLkTi=6RYvEVfKn8ufPEf9meGVEu=fHsQ@mail.gmail.com
Whole thread Raw
In response to Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Josh Kupershmidt
Date:
Subject: psql: missing tab completions for COMMENT ON
Next
From: "Greg Sabino Mullane"
Date:
Subject: Getting a bug tracker for the Postgres project