Re: RES: Priority to a mission critical transaction

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