Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 7723B632FB3
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Sun, 15 Feb 2009 17:02:19 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 84622-07 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Sun, 15 Feb 2009 17:02:16 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 3B5D36321E9
	for <pgsql-admin@postgresql.org>; Sun, 15 Feb 2009 17:02:16 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n1FL26tD026755;
	Sun, 15 Feb 2009 16:02:06 -0500 (EST)
To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
cc: "Scott Marlowe" <scott.marlowe@gmail.com>,
	"Michael Monnerie" <michael.monnerie@is.it-management.at>,
	pgsql-admin@postgresql.org
Subject: Re: Vacuum wait time problem 
In-reply-to: <49980F79.EE98.0025.0@wicourts.gov> 
References: <4995ABC0.4090401@musicreports.com> <200902140102.09224@zmi.at>
	<dcc563d10902131708x2e8dfdadofc6355d8c27c6430@mail.gmail.com>
	<23106.1234576963@sss.pgh.pa.us>
	<dcc563d10902131824n72051a44he60bc8d1d7467e5e@mail.gmail.com>
	<49980F79.EE98.0025.0@wicourts.gov>
Comments: In-reply-to "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
	message dated "Sun, 15 Feb 2009 12:50:01 -0600"
Date: Sun, 15 Feb 2009 16:02:05 -0500
Message-ID: <26754.1234731725@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200902/101
X-Sequence-Number: 31322

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> I don't know what other people have found useful, but when I
> experimented with this in our environment, it seemed like I should
> just treat vacuum_cost_delay as a boolean, where 0 meant off and 10
> meant on, and tune it by adjusting vacuum_cost_limit.  The granularity
> of vacuum_cost_delay is course and surprising unpredictable.

Making it a boolean is a bit further than I care to go ;-)

What I'd suggest at this point is changing the upper limit to 100ms
(from 1000) and adding documentation suggesting that the value should
be kept small, preferring to use the other vacuum_cost parameters to
tune the behavior.

			regards, tom lane