Date: Fri, 30 Apr 2010 23:08:20 -0400
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Rick <richard.branton@ca.com>,
	pgsql-performance@postgresql.org
Subject: Re: autovacuum strategy / parameters
Message-ID: <20100501030820.GI3151@alvh.no-ip.org>
References: <c2d2b6cf-895f-4a4b-aa8b-3adaac33c794@z3g2000yqz.googlegroups.com>
	<y2g603c8f071004221155h3874a3c0ybbe2c790e3c1bf80@mail.gmail.com>
	<65d9d15d-41d2-4bfa-8cc3-6148b4fb9022@z3g2000yqz.googlegroups.com>
	<h2o603c8f071004271755v3e56a408hbd23b5c355058aa@mail.gmail.com>
	<4BDB5ECE.4010607@agliodbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4BDB5ECE.4010607@agliodbs.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

Josh Berkus escribió:

> #autovacuum_vacuum_scale_factor = 0.2
> 
> This is set because in my experience, 20% bloat is about the level at
> which bloat starts affecting performance; thus, we want to vacuum at
> that level but not sooner.  This does mean that very large tables which
> never have more than 10% updates/deletes don't get vacuumed at all until
> freeze_age; this is a *good thing*. VACUUM on large tables is expensive;
> you don't *want* to vacuum a billion-row table which has only 100,000
> updates.

Hmm, now that we have partial vacuum, perhaps we should revisit this.


> It would be worth doing a DBT2/DBT5 test run with different autovac
> settings post-8.4 so see if we should specifically change the vacuum
> threshold.

Right.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.