Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 876539FB1CE
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 28 Nov 2006 21:43:17 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024)
	with ESMTP id 15349-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 28 Nov 2006 21:43:08 -0400 (AST)
X-Greylist: delayed 00:15:01.000718 by SQLgrey-1.7.4
Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68])
	by postgresql.org (Postfix) with ESMTP id 93EF89FA1A1
	for <pgsql-performance@postgresql.org>;
	Tue, 28 Nov 2006 21:43:08 -0400 (AST)
Received: from [192.168.1.11] (218-101-28-54.dsl.clear.net.nz [218.101.28.54])
	by smtp5.clear.net.nz (CLEAR Net Mail)
	with ESMTP id <0J9G005VUXEJ9N00@smtp5.clear.net.nz> for
	pgsql-performance@postgresql.org; Wed, 29 Nov 2006 14:27:56 +1300 (NZDT)
Date: Wed, 29 Nov 2006 14:27:54 +1300
From: Mark Kirkwood <markir@paradise.net.nz>
Subject: Re: RES: Priority to a mission critical transaction
In-reply-to: <456C9CA0.3040604@cheapcomplexdevices.com>
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>
Cc: Andreas Kostyrka <andreas@kostyrka.org>, jim@nasby.net,
	pgsql-performance@postgresql.org
Message-id: <456CE21A.4010004@paradise.net.nz>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
References: <20061127005143.GJ39519@nasby.net>
	<PEEPKDFEHHEMKBBFPOOKMEAIDKAA.carlos.reimer@opendb.com.br>
	<20061128192036.GB7489@andi-lap.la.revver.com>
	<456C9CA0.3040604@cheapcomplexdevices.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20061101)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200611/260
X-Sequence-Number: 22030

Ron Mayer wrote:
> Short summary:
>   * Papers studying priority inversion issues with
>     databases including PosgreSQL and realistic workloads
>     conclude setpriority() helps even in the presence of
>     priority inversion issues for TCP-C and TCP-W like
>     workloads.
>   * Avoiding priority inversion with priority inheritance
>     will further help some workloads (TCP-C) more than
>     others (TCP-W) but even without such schedulers
>     priority inversion does not cause as much harm
>     as the benefit you get from indirectly scheduling
>     I/O through setpriority() in any paper I've seen.
> 
> Andreas Kostyrka wrote:
>> * Carlos H. Reimer <carlos.reimer@opendb.com.br> [061128 20:02]:
>>> Will the setpriority() system call affect i/o queue too?
>> Nope, and in fact the article shows the way not to do it.
> 
> Actually *YES* setpriority() does have an indirect effect
> on the I/O queue.
> 

While I was at Greenplum a related point was made to me:

For a TPC-H/BI type workload on a well configured box the IO subsystem 
can be fast enough so that CPU is the bottleneck for much of the time - 
so being able to use setpriority() as a resource controller makes sense.

Also, with such a workload being mainly SELECT type queries, the dangers 
connected with priority inversion are considerably reduced.

Cheers

Mark