Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
>> Greg Smith wrote:
>>> Count me on the side that agrees adjusting the vacuuming parameters is
>>> the more straightforward way to cope with this problem.
> 
>> Agreed for vacuum; but it still seems interesting to me that
>> across databases and workloads high priority transactions
>> tended to get through faster than low priority ones.  Is there
>> any reason to believe that the drawbacks of priority inversion
>> outweigh the benefits of setting priorities?
> 
> Well, it's unclear, and anecdotal evidence is unlikely to convince
> anybody.  I had put some stock in the CMU paper, but if it's based
> on PG 7.3 then you've got to **seriously** question its relevance
> to the current code.

I was thinking the paper's results might apply more generally
to RDBMS-like applications since they did test 3 of them with
different locking behavior and different bottlenecks.

But true, I should stop bringing up 7.3 examples.


Anecdotally ;-) I've found renice-ing reports to help; especially
in the (probably not too uncommon case) where slow running
batch reporting queries hit different tables than interactive
reporting queries.   I guess that's why I keep defending
priorities as a useful technique.   It seems even more useful
considering the existence of schedulers that have priority
inheritance features.

I'll admit there's still the theoretical possibility that
it's a foot-gun so I don't mind people having to write
their own stored procedure to enable it - but I'd be
surprised if anyone could find a real world case where
priorities would do more harm than good.

Though, yeah, it'd be easy to construct an artificial
case that'd demonstrate priority inversion (i.e. have
a low priority process that takes a lock and sits
and spins on some CPU-intensive stored procedure
without doing any I/O).

---------------------------(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

Reply via email to