Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 7C912B5D944 for ; Fri, 27 May 2011 15:34:28 -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 98369-01 for ; Fri, 27 May 2011 18:34:21 +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 DFD28B5DBD6 for ; Fri, 27 May 2011 15:34:20 -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 p4RIYASc017686; Fri, 27 May 2011 14:34:10 -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> <4DDE7EB8020000250003DDA8@gw.wicourts.gov> <9007.1306446600@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Fri, 27 May 2011 11:07:05 -0400" Date: Fri, 27 May 2011 14:34:10 -0400 Message-ID: <17685.1306521250@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/1433 X-Sequence-Number: 188467 Robert Haas writes: > Still, maybe we don't have a better option. If it were me, I'd add an > additional safety valve: use your formula if the percentage of the > relation scanned is above some threshold where there's unlikely to be > too much skew. But if the percentage scanned is too small, then don't > use that formula. Instead, only update relpages/reltuples if the > relation is now larger; set relpages to the new actual value, and > scale up reltuples proportionately. Ah, progress: now we're down to arguing about the size of the fudge factor ;-). I'll do something involving derating the reliability when the number is coming from VACUUM. regards, tom lane