X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id B3E849DC83C for ; Tue, 7 Feb 2006 02:38:23 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 65652-05 for ; Tue, 7 Feb 2006 02:38:23 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 08E939DC803 for ; Tue, 7 Feb 2006 02:38:20 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 39D3A30945; Tue, 7 Feb 2006 07:38:21 +0100 (MET) From: Christopher Browne X-Newsgroups: pgsql.performance Subject: Re: Default autovacuum settings too conservative Date: Mon, 06 Feb 2006 22:14:53 -0800 Organization: cbbrowne Computing Inc Lines: 22 Message-ID: References: <20060201211633.GM95850@pervasive.com> <43E12A03.6070906@zeut.net> <20060207050545.GZ1240@pervasive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org X-message-flag: Outlook is rather hackable, isn't it? X-Home-Page: http://www.cbbrowne.com/info/ X-Affero: http://svcs.affero.net/rm.php?r=cbbrowne User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) Cancel-Lock: sha1:p+NBh3GhmgqTPYl5/L8RYdKzwGY= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.65 required=5 tests=[AWL=-0.163, INFO_TLD=0.813] X-Spam-Score: 0.65 X-Spam-Level: X-Archive-Number: 200602/53 X-Sequence-Number: 17039 > On Wed, Feb 01, 2006 at 04:37:07PM -0500, Matthew T. O'Connor wrote: >> I think the default settings should be designed to minimize the impact >> autovacuum has on the system while preventing the system from ever >> getting wildly bloated (also protect xid wraparound, but that doesn't >> have anything to do with the thresholds). > > I don't really see the logic behind that. Problems caused by inadequate > vacuuming seem to be much more prevalent than problems caused by vacuum > impacting the system. If vacuum impact is a concern I think it more > reasonable to make the default vacuum_cost_delay non-zero instead. That's a good point. I would not be keen, on the other hand, on having the delays terribly high. Big tables, if delayed significantly, will take plenty longer to vacuum, and I always get paranoid about long running transactions :-). -- let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;; http://linuxdatabases.info/info/postgresql.html This login session: $13.99