Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 6135AB5DC0E for ; Thu, 26 May 2011 17:30:23 -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 94985-02 for ; Thu, 26 May 2011 20:30:16 +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 E00A3B5DC0D for ; Thu, 26 May 2011 17:30:15 -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 p4QKU9M6028830; Thu, 26 May 2011 16:30:09 -0400 (EDT) To: Robert Haas cc: Kevin Grittner , Florian Helmberger , Alvaro Herrera , Greg Stark , pgsql-hackers@postgresql.org 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> <25097.1306426982@sss.pgh.pa.us> <4DDE475B020000250003DD63@gw.wicourts.gov> <4DDE5033020000250003DD71@gw.wicourts.gov> Comments: In-reply-to Robert Haas message dated "Thu, 26 May 2011 15:48:29 -0400" Date: Thu, 26 May 2011 16:30:09 -0400 Message-ID: <28829.1306441809@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/1374 X-Sequence-Number: 188408 Robert Haas writes: > Except that's not how it works. At least in the case of ANALYZE, we > *aren't* counting all the tuples in the table. We're selecting a > random sample of pages and inferring a tuple density, which we then > extrapolate to the whole table and store. Then when we pull it back > out of the table, we convert it back to a tuple density. The real > value we are computing and using almost everywhere is tuple density; > storing a total number of tuples in the table appears to be just > confusing the issue. If we were starting in a green field we might choose to store tuple density. However, the argument for changing it now is at best mighty thin; IMO it is not worth the risk of breaking client code. regards, tom lane