Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 81D259FB263 for ; Wed, 10 Jan 2007 17:21:35 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 91617-07 for ; Wed, 10 Jan 2007 17:21:29 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id ED7CD9FB251 for ; Wed, 10 Jan 2007 17:21:28 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id 1BA8756440; Wed, 10 Jan 2007 15:21:28 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Wed, 10 Jan 2007 15:21:26 -0600 Date: Wed, 10 Jan 2007 15:21:26 -0600 From: "Jim C. Nasby" To: Jeremy Haile , pgsql-performance@postgresql.org Subject: Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum Message-ID: <20070110212125.GZ12217@nasby.net> References: <1168363601.5177.1168380907@webmail.messagingengine.com> <20070110203556.GX12217@nasby.net> <1168461780.9408.1168619515@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1168461780.9408.1168619515@webmail.messagingengine.com> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:070110:jhaile@fastmail.fm::GCsFjLIEGMzAhXAQ:0000000000000000000 0000000000000000000000000fIC X-Hashcash: 1:20:070110:pgsql-performance@postgresql.org::iZcNWFN4Dfp/F9g7:00000 0000000000000000000000008SAx X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/155 X-Sequence-Number: 22756 Please cc the list so others can help and learn. On Wed, Jan 10, 2007 at 03:43:00PM -0500, Jeremy Haile wrote: > > I'd suggest trying autovacuum and see how it does (though you might want > > to tune it to be more or less aggressive, and you'll probably want to > > enable the cost delay). > > What are some decent default values for the cost delay vacuum settings? > I haven't used these before. I find that simply setting vacuum_cost_delay to 20 is generally a good starting point. I'll usually do that and then run a vacuum while watching disk activity; I try and tune it so that the disk is ~90% utilized with vacuum running. That allows a safety margin without stretching vacuums out forever. > Also - do the default autovacuum settings make sense for tables on the > scale of 10 million rows? For example, using the defaults it would > require about a million rows (250 + 0.1 * 10 million) to be > inserted/updated/deleted before analyzing - which seems high. (about 2 > million for vacuum) Or am I overestimating how often I would need to > vacuum/analyze these tables? Depends on your application... the way I look at it is that a setting of 0.1 means 10% dead space in the table. While 5% or 1% would be better, you hit a point of diminishing returns since you have to read the entire table and it's indexes to vacuum it. BTW, that's the default values for analyze... the defaults for vacuum are 2x that. > Do most people use the default autovacuum settings successfully, or are > they usually modified? I generally use the 8.2 defaults (which are much better than the 8.1 defaults) unless I'm really trying to tune things. What's more important is to make sure critical tables (such as queue tables) are getting vacuumed frequently so that they stay small. (Of course you also need to ensure there's no long running transactions). -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net