Re: Buglist
От | Edmund Dengler |
---|---|
Тема | Re: Buglist |
Дата | |
Msg-id | Pine.BSO.4.44.0308201810290.17639-100000@cyclops4.esentire.com обсуждение исходный текст |
Ответ на | Re: Buglist (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
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 >
В списке pgsql-general по дате отправления: