| From: | Brian Hurt <bhurt(at)janestcapital(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: RES: Priority to a mission critical transaction |
| Date: | 2006-11-29 13:25:57 |
| Message-ID: | 456D8A65.3080400@janestcapital.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-advocacy pgsql-performance |
Ron Mayer wrote:
>Before asking them to remove it, are we sure priority inversion
>is really a problem?
>
>I thought this paper: http://www.cs.cmu.edu/~bianca/icde04.pdf
>did a pretty good job at studying priority inversion on RDBMs's
>including PostgreSQL on various workloads (TCP-W and TCP-C) and
>found that the benefits of setting priorities vastly outweighed
>the penalties of priority inversion across all the databases and
>all the workloads they tested.
>
>
>
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.
Brian
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Lewis | 2006-11-29 15:03:44 | Re: RES: Priority to a mission critical transaction |
| Previous Message | Simon Riggs | 2006-11-29 12:48:41 | Re: Integrating Replication into Core |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Lewis | 2006-11-29 15:03:44 | Re: RES: Priority to a mission critical transaction |
| Previous Message | Alessandro Baretta | 2006-11-29 11:31:55 | NAMEDATALEN and performance |