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 <andrew@libertyrms.info> 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 majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
