Re: More thoughts about planner's cost estimates
От | Jim Nasby |
---|---|
Тема | Re: More thoughts about planner's cost estimates |
Дата | |
Msg-id | C28F6D9E-E008-4447-A2A3-2CA20EB60CD1@pervasive.com обсуждение исходный текст |
Ответ на | Re: More thoughts about planner's cost estimates (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: