X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 318B052830 for ; Fri, 20 May 2005 19:21:35 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 08370-09 for ; Fri, 20 May 2005 22:21:28 +0000 (GMT) Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by svr1.postgresql.org (Postfix) with ESMTP id 8407452819 for ; Fri, 20 May 2005 19:21:26 -0300 (ADT) X-EthosMedia-Virus-Scanned: no infections found Received: from [64.81.245.111] (account josh@agliodbs.com HELO temoku.sf.agliodbs.com) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 7387764; Fri, 20 May 2005 15:23:52 -0700 From: Josh Berkus Reply-To: josh@agliodbs.com Organization: Aglio Database Solutions To: "Jim C. Nasby" Subject: Re: Tuning planner cost estimates Date: Fri, 20 May 2005 15:23:16 -0700 User-Agent: KMail/1.7.1 Cc: pgsql-performance@postgresql.org References: <20050518002236.GU30902@decibel.org> <200505190931.47662.josh@agliodbs.com> <20050520202017.GK44623@decibel.org> In-Reply-To: <20050520202017.GK44623@decibel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201523.16437.josh@agliodbs.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.046 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200505/336 X-Sequence-Number: 12500 Jim, > Well, that raises an interesting issue, because AFAIK none of the cost > estimate functions currently do that. Heck, AFAIK even the piggyback > seqscan code doesn't take other seqscans into account. Sure. But you're striving for greater accuracy, no? Actually, all that's really needed in the way of concurrent activity is a calculated factor that lets us know how likely a particular object is to be cached, either in the fs cache or the pg cache (with different factors for each presumably) based on history. Right now, that's based on estimated_cache_size, which is rather innacurate: a table which is queried once a month has the exact same cost factors as one which is queried every 2.1 seconds. This would mean an extra column in pg_stats I suppose. > But ultimately, I'm not sure if this is really required or not, because > I don't see that we need to use explain when running queries. In fact, > it's possibly desireable that we don't, because of the overhead it > incurs. We would want to log an explain (maybe analyze) just to make > sure we knew what the optimizer was doing, but I think we shouldn't need > the info to produce cost estimates. Well, the problem is that you need to know how much time the index scan took vs. other query steps. I don't see a way to do this other than an anayze. -- __Aglio Database Solutions_______________ Josh Berkus Consultant josh@agliodbs.com www.agliodbs.com Ph: 415-752-2500 Fax: 415-752-2387 2166 Hayes Suite 200 San Francisco, CA