To: Ron Mayer <rm_pg@cheapcomplexdevices.com>
cc: Greg Smith <gsmith@gregsmith.com>, pgsql-performance@postgresql.org
Subject: Re: Background vacuum 
In-reply-to: <464D18CE.8070408@cheapcomplexdevices.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>
Comments: In-reply-to Ron Mayer <rm_pg@cheapcomplexdevices.com>
	message dated "Thu, 17 May 2007 20:09:02 -0700"
Date: Thu, 17 May 2007 23:22:04 -0400
Message-ID: <18134.1179458524@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Greg Smith wrote:
>> Count me on the side that agrees adjusting the vacuuming parameters is
>> the more straightforward way to cope with this problem.

> Agreed for vacuum; but it still seems interesting to me that
> across databases and workloads high priority transactions
> tended to get through faster than low priority ones.  Is there
> any reason to believe that the drawbacks of priority inversion
> outweigh the benefits of setting priorities?

Well, it's unclear, and anecdotal evidence is unlikely to convince
anybody.  I had put some stock in the CMU paper, but if it's based
on PG 7.3 then you've got to **seriously** question its relevance
to the current code.

			regards, tom lane