What about the use of priority inheritance to deal with the issue of priority inversion (a standard methodology within the real-time world)?
Then we could have priorities, but still have low priority processes bumped up if a high level one is waiting on them. Regards, Ed On Wed, 20 Aug 2003, Tom Lane wrote: > Andrew Sullivan <[EMAIL PROTECTED]> writes: > >> I disagree. Triggering a vacuum on a db that is nearly saturating the > >> disk bandwidth has a significant impact. > > > Vivek is right about this. If your system is already very busy, then > > a vacuum on a largish table is painful. > > > I don't actually think having the process done in real time will > > help, though -- it seems to me what would be more useful is an even > > lazier vacuum: something that could be told "clean up as cycles are > > available, but make sure you stay out of the way." Of course, that's > > easy to say glibly, and mighty hard to do, I expect. > > I'd love to be able to do that, but I can't think of a good way. > > Just nice'ing the VACUUM process is likely to be counterproductive > because of locking issues (priority inversion). Though if anyone cares > to try it on a heavily-loaded system, I'd be interested to hear the > results... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
