On Jun 4, 2006, at 5:09 PM, Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
>> Hannu Krosing <hannu@skype.net> writes:
>>> Ühel kenal päeval, L, 2006-06-03 kell 10:43, kirjutas Jim Nasby:
>>>> Might also be worth adding analyze delay settings, ala
>>>> vacuum_cost_delay.
>
> ANALYZE already respects the vacuum delay settings.
>
>>> Actually we should have delay settings for all potential
>>> (almost-)full-scan service ops, - VACUUM, ANALYSE, CREATE INDEX, ADD
>>> CONSTRAINT, maybe more - so that there would be better chances of
>>> running those on busy databases without disastrous effects.
>
>> What about UPDATE and DELETE and for that matter SELECT?
>
> This seems pretty silly. The point of the delay stuff is to prevent
> background maintenance operations from eating an unreasonable share
> of resources compared to foreground queries. I don't see why you'd
> put delays into queries --- if your machine is loaded, it's loaded.
'maintenance operations' often also mean running large updates. Being
able to run those at a reduced priority would certainly be helpful in
many cases. Though, a better way to accomplish this would be to have
the OS handle prioritized IO scheduling, but since pretty much none
of them seem to do that...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
