Date: Sat, 19 May 2007 01:27:16 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-performance@postgresql.org
Subject: Re: Background vacuum
In-Reply-To: <464DFCC3.8040207@cheapcomplexdevices.com>
Message-ID: <Pine.GSO.4.64.0705190100570.29971@westnet.com>
References: <4642A1B3.6030009@swissembedded.com>
	<4642A811.9010703@drivefaster.net>
	<4643B490.2040704@cheapcomplexdevices.com>
	<20070517135530.GI6907@phlogiston.dyndns.org>
	<464D04F8.7020306@cheapcomplexdevices.com>
	<Pine.GSO.4.64.0705172246320.20470@westnet.com>
	<464D18CE.8070408@cheapcomplexdevices.com>
	<18134.1179458524@sss.pgh.pa.us>
	<464DFCC3.8040207@cheapcomplexdevices.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 18 May 2007, Ron Mayer wrote:

> Anecdotally ;-) I've found renice-ing reports to help

Let's break this down into individual parts:

1) Is there enough CPU-intensive activity in some database tasks that they 
can be usefully be controlled by tools like nice?  Sure.

2) Is it so likely that you'll fall victim to a priority inversion problem 
that you shouldn't ever consider that technique?  No.

3) Does the I/O scheduler in modern OSes deal with a lot more things than 
just the CPU?  You bet.

4) Is vacuuming a challenging I/O demand?  Quite.

Add all this up, and that fact that you're satisfied with how nice has 
worked successfully for you doesn't have to conflict with an opinion that 
it's not the best approach for controlling vacuuming.  I just wouldn't 
extrapolate your experience too far here.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD