X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 8395E9FA5EA for ; Wed, 7 Jun 2006 08:42:37 -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 99555-10 for ; Wed, 7 Jun 2006 08:42:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sand2.gxn.net (sand2.gxn.net [195.147.249.208]) by postgresql.org (Postfix) with ESMTP id A9D829FA5D3 for ; Wed, 7 Jun 2006 08:42:32 -0300 (ADT) Received: from [62.232.55.118] (helo=[192.168.0.2]) by sand2.gxn.net with esmtp (Exim 4.50) id 1FnwSE-0002Bq-OK; Wed, 07 Jun 2006 12:44:06 +0100 Subject: Re: Some queries starting to hang From: Simon Riggs To: Tom Lane Cc: "Jim C. Nasby" , Andrew Sullivan , pgsql-performance@postgresql.org In-Reply-To: <17758.1149608475@sss.pgh.pa.us> References: <1149534308.3583.56.camel@bg002441.pro-unlimited.com> <22706.1149538039@sss.pgh.pa.us> <20060605203851.GB7071@phlogiston.dyndns.org> <23915.1149541591@sss.pgh.pa.us> <1149604741.2621.487.camel@localhost.localdomain> <17148.1149605005@sss.pgh.pa.us> <1149605576.2621.502.camel@localhost.localdomain> <17426.1149606369@sss.pgh.pa.us> <20060606151416.GD53487@pervasive.com> <17758.1149608475@sss.pgh.pa.us> Content-Type: text/plain Date: Wed, 07 Jun 2006 12:42:28 +0100 Message-Id: <1149680548.2621.600.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/75 X-Sequence-Number: 19432 On Tue, 2006-06-06 at 11:41 -0400, Tom Lane wrote: > "Jim C. Nasby" writes: > > On Tue, Jun 06, 2006 at 11:06:09AM -0400, Tom Lane wrote: > >> I don't think that helps, as it just replaces one uncertainty by > >> another: how far did the EXPLAIN really get towards completion of the > >> plan? You still don't have any hard data. > > > Does that really matter, though? The point is to find the node where the > > estimate proved to be fantasy. > > No, the point is to find out what reality is. My point is knowing reality with less than 100% certainty is still very frequently useful. > Just knowing that the > estimates are wrong doesn't really get you anywhere (we pretty much knew > that before we even started looking at the EXPLAIN, eh?). We were lucky enough to have two EXPLAINS that could be examined for differences. Often, you have just one EXPLAIN and no idea which estimate is incorrect, or whether they are all exactly correct. That is when an EXPLAIN ANALYZE becomes essential - yet a *full* execution isn't required in order to tell you what you need to know. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com