Subject: Re: RES: Priority to a mission critical transaction
From: Mark Lewis <mark.lewis@mir3.com>
To: Brian Hurt <bhurt@janestcapital.com>
Cc: pgsql-performance@postgresql.org
In-Reply-To: <456D8A65.3080400@janestcapital.com>
References: <4939.1164740825@sss.pgh.pa.us>
	<200611282344.kASNijt09203@momjian.us>
	<456CE066.50803@cheapcomplexdevices.com>
	<456D8A65.3080400@janestcapital.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: MIR3, Inc.
Date: Wed, 29 Nov 2006 07:03:44 -0800
Message-Id: <1164812624.9690.500.camel@archimedes>
Mime-Version: 1.0

On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
...
> I have the same question.  I've done some embedded real-time 
> programming, so my innate reaction to priority inversions is that 
> they're evil.  But, especially given priority inheritance, is there any 
> situation where priority inversion provides *worse* performance than 
> running everything at the same priority?  I can easily come up with 
> situations where it devolves to that case- where all processes get 
> promoted to the same high priority.  But I can't think of one where 
> using priorities makes things worse, and I can think of plenty where it 
> makes things better.
...

It can make things worse when there are at least 3 priority levels
involved.  The canonical sequence looks as follows:

LOW:  Aquire a lock
MED:  Start a long-running batch job that hogs CPU
HIGH: Wait on lock held by LOW task

at this point, the HIGH task can't run until the LOW task releases its
lock. but the LOW task can't run to completion and release its lock
until the MED job completes.

(random musing): I wonder if PG could efficiently be made to temporarily
raise the priority of any task holding a lock that a high priority task
waits on.  I guess that would just make it so that instead of HIGH tasks
being effectively reduced to LOW, then LOW tasks could be promoted to
HIGH.

-- Mark Lewis