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=jcKSU5zR+JG2BvfLNCtezC9sb+g@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 Wed, May 25, 2011 at 9:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, I had been thinking about the latter point.  We could be
> conservative and just keep the reported tuple density the same (ie,
> update relpages to the new correct value, while setting reltuples so
> that the density ratio doesn't change).  But that has its own problems
> when the table contents *do* change.  What I'm currently imagining is
> to do a smoothed moving average, where we factor in the new density
> estimate with a weight dependent on the percentage of the table we did
> scan.  That is, the calculation goes something like
>
> old_density = old_reltuples / old_relpages
> new_density = counted_tuples / scanned_pages
> reliability = scanned_pages / new_relpages
> updated_density = old_density + (new_density - old_density) * reliability
> new_reltuples = updated_density * new_relpages

This amounts to assuming that the pages observed in the vacuum have
the density observed and the pages that weren't seen have the density
that were previously in the reltuples/relpages stats. That seems like
a pretty solid approach to me. If the numbers were sane before it
follows that they should be sane after the update.

--
greg


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Next
From: Heikki Linnakangas
Date:
Subject: Re: SSI predicate locking on heap -- tuple or row?