Re: [GENERAL] Change query priority
Thats fine, but you do understand that nice (linux) will have *no* effect on I/O? For any non-trivial table (that can't be held entirely in memory), re-nice will almost certainly have no effect. -Barry In article [EMAIL PROTECTED], Gaetano Mendola wrote: Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: I feel that renice a backend will not kill your system. It won't kill the system, but it probably won't accomplish what you hoped for, either. That's true but right now renice a backend is the only way to procede in order to *try* to slow down some queries Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Change query priority
Barry S wrote: Thats fine, but you do understand that nice (linux) will have *no* effect on I/O? I do. For any non-trivial table (that can't be held entirely in memory), re-nice will almost certainly have no effect. That's my feeling too, but at least is a try. Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Change query priority
Tom Lane wrote: Michael Fuhr [EMAIL PROTECTED] 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. Without change priority doesn't means we are immune to a priority inversion, for example the way semaphore are implemented in Linux doesn't prevent you to be bitten, at least IIRC the Linux kernel doesn't trace chain locks... however I'd ve worried about priority inversion if I have hard deadline, have hard deadline and database in the same sentence is like put windows and security in the same sentence too... I feel that renice a backend will not kill your system. Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Change query priority
Gaetano Mendola [EMAIL PROTECTED] writes: I feel that renice a backend will not kill your system. It won't kill the system, but it probably won't accomplish what you hoped for, either. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Change query priority
Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: I feel that renice a backend will not kill your system. It won't kill the system, but it probably won't accomplish what you hoped for, either. That's true but right now renice a backend is the only way to procede in order to *try* to slow down some queries Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
