Received: from localhost (unknown [200.46.204.187])
	by postgresql.org (Postfix) with ESMTP id A79A42E00E1
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 14 Dec 2007 11:19:28 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024)
	with ESMTP id 50908-06 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 14 Dec 2007 11:19:04 -0400 (AST)
Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
	by postgresql.org (Postfix) with ESMTP id 5A8792E00DB
	for <pgsql-performance@postgresql.org>;
	Fri, 14 Dec 2007 11:19:22 -0400 (AST)
Received: from Courts-MTA by gwmta.wicourts.gov
	with Novell_GroupWise; Fri, 14 Dec 2007 09:19:20 -0600
Message-Id: <47624A8E.EE98.0025.0@wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 7.0.2 
Date: Fri, 14 Dec 2007 09:19:11 -0600
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Russell Smith" <mr-russ@pws.com.au>,
	"Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Simon Riggs" <simon@2ndquadrant.com>, <pgsql-performance@postgresql.org>
Subject: Re: Heavy write activity on first vacuum of fresh
	TOAST data
References: <4760FF69.EE98.0025.0@wicourts.gov>
	<1197562283.4255.1829.camel@ebony.site>
	<47611B9D.EE98.0025.0@wicourts.gov>
	<1197569564.4255.1855.camel@ebony.site>
	<47614D86.EE98.0025.0@wicourts.gov>
	<1197582010.4255.1912.camel@ebony.site>
	<47623103.7030700@pws.com.au><47623103.7030700@pws.com.au>
	<29185.1197618162@sss.pgh.pa.us>
In-Reply-To: <29185.1197618162@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200712/211
X-Sequence-Number: 28027

>>> On Fri, Dec 14, 2007 at  1:42 AM, in message <29185.1197618162@sss.pgh.=
pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> wrote:=20
=20
> My feeling is that vacuum's purpose in life is to offload maintenance
> cycles from foreground queries, so we should be happy to have it setting
> all the hint bits.
=20
Absolutely.
=20
> If Kevin doesn't like the resultant I/O load then he
> should use the vacuum_cost_delay parameters to dial down vacuum speed.
=20
It's not that I don't like it -- I'm often called upon to diagnose
issues, and understanding the dynamics of things like this helps me
interpret what I'm seeing.  No complaint here.
=20
-Kevin
=20