Skip site navigation (1) Skip section navigation (2)

Re: RES: Priority to a mission critical transaction

From: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
To: Brian Hurt <bhurt(at)janestcapital(dot)com>
Subject: Re: RES: Priority to a mission critical transaction
Date: 2006-11-29 18:47:00
Message-ID: 456DD5A4.7030309@cheapcomplexdevices.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-performance
Brian Hurt wrote:
> Ron Mayer wrote:
>> Brian Hurt wrote: 
>>> Mark Lewis wrote:    
>>>> On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
>>>>> But, especially given priority inheritance, is there any 
> 
> That second paper is interesting in that it says that STM solves the
> priority inversion problem.  Basically the higher priority process
> forces the lower priority process to abort it's transaction and retry it.
> 
> Is it possible to recast Postgres' use of locks to use STM instead? 

If I read the CMU paper right (http://www.cs.cmu.edu/~bianca/icde04.pdf),
that's equivalent to what they call "preemptive abort scheduling"
and tested as well as priority inversion.

They did test this and compared it to priority inversion with
postgresql and found them about equivalent.

  "Preemptive scheduling (P-LQ and P-CPU) attempts to eliminate the
  wait excess for high-priority transactions by preempting low-priority
  lock holders in the way of high-priority transactions.  We find that
  preemptive policies provide little benefit
  ...
  TPC-C running on PostgreSQL ... Preemption (P-CPU) provides
  no appreciable benefit over CPU-Prio-Inherit."


> Setting priorities would be a solution to a problem I haven't hit yet,
> but can see myself needing to deal with.  Which is why I'm interested in
> this issue.  If it's a case of "setting priorities can make things
> better, and doesn't make things worse" is great.  If it's a case of
> "setting priorities can make things better, but occassionally makes
> things much worse" is a problem.

From the papers, it seems to depend quite a bit on the workload.

Every actual experiment I've seen published suggests that on the
average the higher-priority transactions will do better - but that
there is the risk of specific individual high priority transactions
that can be slower than they would have otherwise been.

I have yet to see a case where anyone measured anything getting
"much" worse, though.


>>> Of course, this is a little tricky to implement.  I haven't looked at
>>> how difficult it'd be within Postgres.
>>
>> ISTM that it would be rather OS-dependent anyway.  Different OS's
>> have different (or no) hooks - heck, even different 2.6.* linuxes
>> (pre 2.6.18 vs post) have different hooks for priority
>> inheritance - so I wouldn't really expect to see cpu scheduling
>> policy details like that merged with postgresql except maybe from
>> a patched version from a RTOS vendor.
>>
>>   
> Hmm.  I was thinking of Posix.4's setpriority() call.
> 

Hmm - I thought you were thinking the priority inheritance would
be using something like the priority-inheriting
futexes that were added to the linux kernel in 2.6.18.
http://lwn.net/Articles/178253/
http://www.linuxhq.com/kernel/v2.6/18/Documentation/pi-futex.txt

In response to

pgsql-performance by date

Next:From: Mark JensenDate: 2006-11-29 19:43:39
Subject: Fw: [GENERAL] Including unique users in huge data warehouse in Postgresql...
Previous:From: Kevin KempterDate: 2006-11-29 18:03:03
Subject: OT - how to size/match multiple databases/apps for a single server

pgsql-advocacy by date

Next:From: Josh BerkusDate: 2006-11-29 19:08:05
Subject: Releases & schedule sent out
Previous:From: nhrcommuDate: 2006-11-29 18:46:32
Subject: Re: Collateral for LISA 06

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group