Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 3D28CB5DBF8 for ; Wed, 25 May 2011 14:13:42 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 30966-03 for ; Wed, 25 May 2011 17:13:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from spinlock.commandprompt.com (host-215.commandprompt.net [207.173.203.215]) by mail.postgresql.org (Postfix) with ESMTP id 87BDEB5DBE5 for ; Wed, 25 May 2011 14:13:34 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by spinlock.commandprompt.com (Postfix) with ESMTP id 850CC348045; Wed, 25 May 2011 10:13:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at commandprompt.com Received: from spinlock.commandprompt.com ([127.0.0.1]) by localhost (spinlock.commandprompt.com.commandprompt.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKVdHORyo6vG; Wed, 25 May 2011 10:13:31 -0700 (PDT) Received: from perhan.alvh.no-ip.org (unknown [190.95.22.219]) by spinlock.commandprompt.com (Postfix) with ESMTPSA id 498D5348044; Wed, 25 May 2011 10:13:31 -0700 (PDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 6143B6E3FB; Wed, 25 May 2011 13:13:28 -0400 (CLT) Content-Type: text/plain; charset=UTF-8 Cc: Tom Lane , Florian Helmberger , pgsql-hackers Subject: Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum From: Alvaro Herrera To: Robert Haas In-reply-to: References: <4DD28F73.6010108@25th-floor.com> <25017.1306291669@sss.pgh.pa.us> <4DDCA801.70805@25th-floor.com> <19738.1306338472@sss.pgh.pa.us> <22497.1306341699@sss.pgh.pa.us> Date: Wed, 25 May 2011 13:13:28 -0400 Message-Id: <1306343006-sup-4509@alvh.no-ip.org> User-Agent: Sup/git Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=-5 required=5 tests=none X-Spam-Level: X-Archive-Number: 201105/1287 X-Sequence-Number: 188321 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 The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support