Eduardo Piombino wrote:
In the case where priority inversion is not to be used, I would however still greatly benefit from the slow jobs/fast jobs mechanism, just being extra-careful that the slow jobs, obviously, did not acquire any locks that a fast job would ever require. This alone would be, still, a *huge* feature if it was ever to be introduced, reinforcing the real-time awareness/requirements, that many applications look for today.
In this context, "priority inversion" is not a generic term related to running things with lower priorities. It means something very specific: that you're allowing low-priority jobs to acquire locks on resources needed by high-priority ones, and therefore blocking the high-priority ones from running effectively. Unfortunately, much like deadlock, it's impossible to avoid the problem in a generic way just by being careful. It's one of the harder issues that needs to be considered in order to make progress on implementing this feature one day.
-- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
