Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 62232B5DC13 for ; Thu, 26 May 2011 13:24:46 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 53789-03-8 for ; Thu, 26 May 2011 16:24:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 4EB22B5DCD1 for ; Thu, 26 May 2011 13:24:22 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p4QGN2Lo025098; Thu, 26 May 2011 12:23:02 -0400 (EDT) To: Robert Haas cc: Greg Stark , Florian Helmberger , pgsql-hackers@postgresql.org, Alvaro Herrera Subject: Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum 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> <15043.1306423500@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Thu, 26 May 2011 11:55:58 -0400" Date: Thu, 26 May 2011 12:23:02 -0400 Message-ID: <25097.1306426982@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201105/1356 X-Sequence-Number: 188390 Robert Haas writes: > I would feel a lot better about something that is deterministic, like, > I dunno, if VACUUM visits more than 25% of the table, we use its > estimate. And we always use ANALYZE's estimate. Or something. This argument seems to rather miss the point. The data we are working from is fundamentally not deterministic, and you can't make it so by deciding to ignore what data we do have. That leads to a less useful estimate, not a more useful estimate. > Another thought: Couldn't relation_needs_vacanalyze() just scale up > reltuples by the ratio of the current number of pages in the relation > to relpages, just as the query planner does? Hmm ... that would fix Florian's immediate issue, and it does seem like a good change on its own merits. But it does nothing for the problem that we're failing to put the best available information into pg_class. Possibly we could compromise on doing just that much in the back branches, and the larger change for 9.1? regards, tom lane