Skip site navigation (1) Skip section navigation (2)

Re: More thoughts about planner's cost estimates

From: Jim Nasby <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Hannu Krosing <hannu(at)skype(dot)net>, "Todd A(dot)Cook" <tcook(at)blackducksoftware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: More thoughts about planner's cost estimates
Date: 2006-06-05 13:29:56
Message-ID: C28F6D9E-E008-4447-A2A3-2CA20EB60CD1@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jun 4, 2006, at 5:09 PM, Tom Lane wrote:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> Hannu Krosing <hannu(at)skype(dot)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(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461




In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2006-06-05 14:16:42
Subject: Re: 'CVS-Unknown' buildfarm failures?
Previous:From: Jim NasbyDate: 2006-06-05 13:19:59
Subject: Re: 'CVS-Unknown' buildfarm failures?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group