Re: low priority postmaster threads?
От | Tom Lane |
---|---|
Тема | Re: low priority postmaster threads? |
Дата | |
Msg-id | 12895.982797003@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: low priority postmaster threads? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I wrote: > Chris Storah <cstorah@emis-support.demon.co.uk> writes: >> What I am looking for is a postgres system that runs 100 users or so at >> 'full speed', and major day long queries at a 'when idle' priority. > The trouble here is that CPU nice doesn't (on most platforms) change the > behavior of the I/O scheduler, so this would only be of use to the > extent that your queries are CPU bound and not I/O bound. Now that I think twice, there's an even more severe problem with trying to nice() down an individual backend, namely priority inversion. What happens when the low-priority process holds some lock or other, and then a higher-priority process comes along and wants the lock? The high-priority process has to wait, that's what. But there's no mechanism to raise the priority of the lower-priority lock holder, which means that the high-priority process is now effectively lowered to the lower priority; it may have to wait quite a long time, if there are other high-priority processes sucking CPU away from the low-priority guy. In short, forget about nice'ing an individual backend; you probably won't like the results. Sorry. regards, tom lane
В списке pgsql-hackers по дате отправления: