Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Florian Helmberger <fh(at)25th-floor(dot)com>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Date: 2011-05-25 16:17:11
Message-ID: BANLkTi=973Arh-nXLO6YFP7_ZTCeNp-X7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On Wed, May 25, 2011 at 11:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 2. Revise the vacuum code so that it doesn't skip updating the pg_class
> entries.  We could have it count the number of pages it skipped, rather
> than just keeping a bool, and then scale up the rel_tuples count to be
> approximately right by assuming the skipped pages have tuple density
> similar to the scanned ones.

This approach doesn't seem like a good idea to me. The skipped
portions of the table are the ones that haven't been modified in a
while, so this is or embeds an assumption that the tuples in the hot
and cold portions of the table are the same size. That might be true,
but it isn't hard to think of cases where it might not be. There
could also very easily be sampling error, because it's easy to imagine
a situation where 99% of the table is getting skipped. Any error that
creeps into the estimate is going to get scaled up along with the
estimate itself.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2011-05-25 16:23:56 Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Previous Message Alvaro Herrera 2011-05-25 16:00:38 Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-05-25 16:18:53 Re: New/Revised TODO? Gathering actual read performance data for use by planner
Previous Message Robert Haas 2011-05-25 16:12:50 Re: tackling full page writes