From: | Chris Storah <cstorah(at)emis-support(dot)demon(dot)co(dot)uk> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: low priority postmaster threads? |
Date: | 2001-02-22 09:25:42 |
Message-ID: | C05E7DA1218ED411BF8A00105AC95A8E017AFC20@SV-CNTRMAIL |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | hubert depesz lubaczewski | 2001-02-22 09:39:19 | Re: problem while compiling user c functions in 7.1beta4 |
Previous Message | Christopher Sawtell | 2001-02-22 09:21:12 | Re: [GENERAL] problem while compiling user c functions in 7.1beta4 |