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 A8AB89DC83C for ; Tue, 7 Feb 2006 03:26:42 -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 70082-10 for ; Tue, 7 Feb 2006 03:26:41 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 816F29DC807 for ; Tue, 7 Feb 2006 03:26:35 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id DB8083982E; Tue, 7 Feb 2006 07:26:21 +0000 (UTC) Date: Tue, 7 Feb 2006 01:26:21 -0600 From: "Jim C. Nasby" To: Christopher Browne Cc: pgsql-performance@postgresql.org Subject: Re: Default autovacuum settings too conservative Message-ID: <20060207072621.GI13592@pervasive.com> References: <20060201211633.GM95850@pervasive.com> <43E12A03.6070906@zeut.net> <20060207050545.GZ1240@pervasive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 6.0-RELEASE amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.104 required=5 tests=[AWL=0.104] X-Spam-Score: 0.104 X-Spam-Level: X-Archive-Number: 200602/54 X-Sequence-Number: 17040 On Mon, Feb 06, 2006 at 10:14:53PM -0800, Christopher Browne wrote: > > 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 :-). Very true, but I'd hope anyone running a table large enough for this to make a difference would have done some tuning of their own... What we really need is a replacement for vacuum_delay that takes PostgreSQL generated IO activity into account... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461