Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 9A6219FB7A1 for ; Mon, 5 Mar 2007 15:22:21 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 78624-07 for ; Mon, 5 Mar 2007 15:22:17 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from rivendell.solution-x.com (rivendell.solution-x.com [213.147.174.20]) by postgresql.org (Postfix) with ESMTP id 492E39FB7D4 for ; Mon, 5 Mar 2007 15:22:17 -0400 (AST) Received: (qmail 9138 invoked from network); 5 Mar 2007 19:22:12 -0000 Received: from qmail by qscan (mail filter); 5 Mar 2007 19:22:12 +0000 Received: from unknown (HELO [10.100.5.180]) (fgp@[10.100.5.180]) (envelope-sender ) by rivendell.solution-x.com (qmail-ldap-1.03) with SMTP for ; 5 Mar 2007 19:22:12 -0000 Message-ID: <45EC6F02.1050306@phlo.org> Date: Mon, 05 Mar 2007 20:26:58 +0100 From: "Florian G. Pflug" User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Tom Lane CC: ITAGAKI Takahiro , pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org Subject: Re: Aggressive freezing in lazy-vacuum References: <20070227141958.638D.ITAGAKI.TAKAHIRO@oss.ntt.co.jp> <20070227170613.GK29041@nasby.net> <20070305182401.C4BC.ITAGAKI.TAKAHIRO@oss.ntt.co.jp> <18982.1173110551@sss.pgh.pa.us> In-Reply-To: <18982.1173110551@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.061 tagged_above=0 required=5 tests=AWL, BAYES_50, UNPARSEABLE_RELAY X-Spam-Level: X-Archive-Number: 200703/303 X-Sequence-Number: 99787 Tom Lane wrote: > ITAGAKI Takahiro writes: >> This is a stand-alone patch for aggressive freezing. I'll propose >> to use OldestXmin instead of FreezeLimit as the freeze threshold >> in the circumstances below: > > I think it's a really bad idea to freeze that aggressively under any > circumstances except being told to (ie, VACUUM FREEZE). When you > freeze, you lose history information that might be needed later --- for > forensic purposes if nothing else. You need to show a fairly amazing > performance gain to justify that, and I don't think you can. There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit would be calculated as GetOldestXmin() - vacuum_freeze_limit The default for vacuum_freeze_limit would be MaxTransactionId/2, just as it is now. greetings, Florian Pflug