Re: RES: Priority to a mission critical transaction

[Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>]

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(dot)reimer(at)opendb(dot)com(dot)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