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

Re: More thoughts about planner's cost estimates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Hannu Krosing <hannu(at)skype(dot)net>, Jim Nasby <jnasby(at)pervasive(dot)com>, "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-04 22:09:06
Message-ID: 2579.1149458946@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Hannu Krosing <hannu(at)skype(dot)net> writes:
>> hel kenal peval, 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.

I think the existing features are sufficient in this line and that
doing more is just adding complexity for complexity's sake.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Zoltan BoszormenyiDate: 2006-06-04 22:32:38
Subject: Re: psql -A (unaligned format) eats too much memory
Previous:From: Zoltan BoszormenyiDate: 2006-06-04 22:01:24
Subject: psql -A (unaligned format) eats too much memory

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