From: Mark Lewis <mark.lewis@mir3.com>
To: Brian Hurt <bhurt@janestcapital.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: RES: Priority to a mission critical transaction
Date: Wed, 29 Nov 2006 07:03:44 -0800
Message-ID: <1164812624.9690.500.camel@archimedes> (raw)
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>
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
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: mark.lewis@mir3.com, bhurt@janestcapital.com
Subject: Re: RES: Priority to a mission critical transaction
In-Reply-To: <1164812624.9690.500.camel@archimedes>
* 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