From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | Eugeny Balakhonov <c0ff75(at)mail(dot)ru>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Change query priority |
Date: | 2004-10-10 16:29:32 |
Message-ID: | 11094.1097425772@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> I don't know how effective this would be, but you could wrap the
> system call setpriority() in a user-defined function if your
> platform supports it. This would set the "nice" value of the
> backend process, which might serve as a crude prioritization
> mechanism.
Every couple of months someone comes along and says "why don't you
provide a way to renice a backend" ... but in point of fact it's
somewhere between useless and counterproductive for most query loads.
The "useless" part comes in because nice only affects CPU priority not
I/O priority, but I/O load is the thing that counts for most database
applications. The "counterproductive" part comes in because of an
effect called priority inversion. The niced-down process may be holding
a lock that is wanted by some higher-priority process --- but the kernel
scheduler knows nothing of that, and will leave the niced-down process
at the bottom of the queue, and thus the high-priority process is
effectively stuck at the bottom too.
If this were an easy problem to solve we'd have offered a solution long
ago ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2004-10-10 16:42:14 | Re: Change query priority |
Previous Message | Michael Fuhr | 2004-10-10 16:05:56 | Re: Change query priority |