Tom Lane Wrote:
> 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.
Assuming there is a major processor hit, and the backend has a UW-SCSI RAID
box with enough I/O capability...
>What happens when the low-priority process holds some lock or other,
>and then a higher-priority process comes along and wants the lock?
If the query was a select only, would the locking problem still apply?
(The long queries in this case are in the form of 'select * from [all tables
joined together] where x')
I will make a couple of changes and test it to see if there are any
performance gains in particular cases.
The other option is to add another processor :)
Chris
