Re: RES: Priority to a mission critical transaction - Mailing list pgsql-performance

From Mark Kirkwood
Subject Re: RES: Priority to a mission critical transaction
Date
Msg-id 456CE21A.4010004@paradise.net.nz
Whole thread Raw
In response to Re: RES: Priority to a mission critical transaction  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Responses Re: RES: Priority to a mission critical transaction  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-performance
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.reimer@opendb.com.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

pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: RES: Priority to a mission critical transaction
Next
From: Ron Mayer
Date:
Subject: Re: RES: Priority to a mission critical transaction