From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Background vacuum
Date: Fri, 18 May 2007 12:21:39 -0700
Message-ID: <464DFCC3.8040207@cheapcomplexdevices.com> (raw)
In-Reply-To: <18134.1179458524@sss.pgh.pa.us>
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>
Tom Lane wrote:
> 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.
I was thinking the paper's results might apply more generally
to RDBMS-like applications since they did test 3 of them with
different locking behavior and different bottlenecks.
But true, I should stop bringing up 7.3 examples.
Anecdotally ;-) I've found renice-ing reports to help; especially
in the (probably not too uncommon case) where slow running
batch reporting queries hit different tables than interactive
reporting queries. I guess that's why I keep defending
priorities as a useful technique. It seems even more useful
considering the existence of schedulers that have priority
inheritance features.
I'll admit there's still the theoretical possibility that
it's a foot-gun so I don't mind people having to write
their own stored procedure to enable it - but I'd be
surprised if anyone could find a real world case where
priorities would do more harm than good.
Though, yeah, it'd be easy to construct an artificial
case that'd demonstrate priority inversion (i.e. have
a low priority process that takes a lock and sits
and spins on some CPU-intensive stored procedure
without doing any I/O).
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: rm_pg@cheapcomplexdevices.com, tgl@sss.pgh.pa.us
Subject: Re: Background vacuum
In-Reply-To: <464DFCC3.8040207@cheapcomplexdevices.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox