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 9DC839FA5CE for ; Sun, 4 Jun 2006 18:35:14 -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 55679-03 for ; Sun, 4 Jun 2006 18:35:06 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by postgresql.org (Postfix) with ESMTP id 6906C9F9316 for ; Sun, 4 Jun 2006 18:35:06 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1Fn0FE-0004Hg-00; Sun, 04 Jun 2006 17:34:48 -0400 To: Hannu Krosing Cc: Jim Nasby , "Todd A.Cook" , pgsql-hackers@postgresql.org Subject: Re: More thoughts about planner's cost estimates 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> In-Reply-To: <1149360367.3889.8.camel@localhost.localdomain> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 04 Jun 2006 17:34:47 -0400 Message-ID: <87mzcsbo5k.fsf@stark.xeocode.com> Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/142 X-Sequence-Number: 84375 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. > > 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? -- greg