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

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

Excerpts from Robert Haas's message of mié may 25 12:54:28 -0400 2011:

> I don't know. That's maybe better, but I'd be willing to wager that
> in some cases it will just slow down the rate at which we converge to
> a completely incorrect value, while in other cases it'll fail to
> update the data when it really has changed.

For regular tables I don't think there's a real problem because it'll
get fixed next time a full scan happens anyway. For toast tables, I
think the set of operations is limited enough that this is easy to prove
correct (or fixed so that it is) -- no HOT updates (in fact no updates
at all), etc.

BTW one thing we haven't fixed at all is how do HOT updates affect
vacuuming behavior ...

> I am wondering, though, why we're not just inserting a special-purpose
> hack for TOAST tables. Your email seems to indicate that regular
> tables are already handled well enough, and certainly if we only whack
> around the TOAST behavior it's much less likely to fry anything.

Well, having two paths one of which is uncommonly used means that it
will get all the bugs. As with the xl_commit WAL record comment from
Simon, I'd rather stick with having a single one.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Robert Haas 2011-05-25 17:15:59 Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Previous Message Tom Lane 2011-05-25 17:04:27 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 17:15:59 Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Previous Message Tom Lane 2011-05-25 17:11:33 Re: Nested CASE-WHEN scoping