X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id EFC4D9FA2DB for ; Mon, 5 Jun 2006 06:34:10 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 11561-04 for ; Mon, 5 Jun 2006 06:34:00 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.skype.net (mail.skype.net [195.215.8.149]) by postgresql.org (Postfix) with ESMTP id C0EE09FA2BC for ; Mon, 5 Jun 2006 06:34:00 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E1E304E124; Mon, 5 Jun 2006 11:33:57 +0200 (CEST) Received: from [10.10.10.3] (217-159-136-226-dsl.kt.estpak.ee [217.159.136.226]) by mail.skype.net (Postfix) with ESMTP id 164C64E05B; Mon, 5 Jun 2006 11:32:10 +0200 (CEST) Subject: Re: More thoughts about planner's cost estimates From: Hannu Krosing To: Tom Lane Cc: Greg Stark , Jim Nasby , "Todd A.Cook" , pgsql-hackers@postgresql.org 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> Content-Type: text/plain; charset=utf-8 Date: Mon, 05 Jun 2006 12:28:08 +0300 Message-Id: <1149499689.6204.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/147 X-Sequence-Number: 84380 Ühel kenal päeval, P, 2006-06-04 kell 18:09, kirjutas Tom Lane: > Greg Stark writes: > > Hannu Krosing 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