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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
