From: Hannu Krosing <hannu@skype.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <gsstark@mit.edu>
Cc: Jim Nasby <jnasby@pervasive.com>
Cc: Todd A.Cook <tcook@blackducksoftware.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: More thoughts about planner's cost estimates
Date: Mon, 05 Jun 2006 12:28:08 +0300
Message-ID: <1149499689.6204.25.camel@localhost.localdomain> (raw)
In-Reply-To: <2579.1149458946@sss.pgh.pa.us>
References: <14821.1149104747@sss.pgh.pa.us>
<10464.1149281016@sss.pgh.pa.us>
<87k67zdymk.fsf@stark.xeocode.com>
<200606021515.44174.josh@agliodbs.com>
<4480BAA1.9040907@blackducksoftware.com>
<0B801F97-877B-49FE-88DA-8C0083FA0CE5@pervasive.com>
<1149360367.3889.8.camel@localhost.localdomain>
<87mzcsbo5k.fsf@stark.xeocode.com>
<2579.1149458946@sss.pgh.pa.us>
Ühel kenal päeval, P, 2006-06-04 kell 18:09, kirjutas Tom Lane:
> 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.
>
> I think the existing features are sufficient in this line and that
> doing more is just adding complexity for complexity's sake.
Making CREATE INDEX respect delay settings will be reasonable once we
get it to run without locking the table.
And if non-locking is doable for ADD/ALTER CONSTRAINT, then it makes
sense there too.
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: hannu@skype.net, tgl@sss.pgh.pa.us, gsstark@mit.edu, jnasby@pervasive.com, tcook@blackducksoftware.com
Subject: Re: More thoughts about planner's cost estimates
In-Reply-To: <1149499689.6204.25.camel@localhost.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox