On Jun 4, 2006, at 5:09 PM, Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Hannu Krosing <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
