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