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 AC5889FB1B9 for ; Tue, 6 Jun 2006 18:14:58 -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 58799-05 for ; Tue, 6 Jun 2006 18:14:49 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id 2E1229FA13E for ; Tue, 6 Jun 2006 18:14:49 -0300 (ADT) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Jun 2006 21:14:47 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 06 Jun 2006 16:14:48 -0500 Subject: Re: Some queries starting to hang From: Scott Marlowe To: Tom Lane Cc: "Jim C. Nasby" , "Craig A. James" , pgsql-performance@postgresql.org In-Reply-To: <23270.1149628274@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> <4485C061.2080206@modgraph-usa.com> <1149616467.25526.213.camel@state.g2switchworks.com> <20060606205117.GB45331@pervasive.com> <1149627741.25526.224.camel@state.g2switchworks.com> <23270.1149628274@sss.pgh.pa.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1149628487.25526.228.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 06 Jun 2006 16:14:48 -0500 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/73 X-Sequence-Number: 19430 On Tue, 2006-06-06 at 16:11, Tom Lane wrote: > Scott Marlowe writes: > > The cost of not aborting on the first sort is that you may never see > > what the part of the plan is that's killing your query, since you never > > get the actual plan. > > Well, you can get the plan without waiting a long time; that's what > plain EXPLAIN is for. But I still disagree with the premise that you > can extrapolate anything very useful from an unfinished EXPLAIN ANALYZE > run. As an example, if the plan involves setup steps such as sorting or > loading a hashtable, cancelling after a minute might make it look like > the setup step is the big problem, distracting you from the possibility > that the *rest* of the plan would take weeks to run if you ever got to > it. Sure, but it would be nice to see it report the partial work. i.e. I got to using a nested loop, thought there would be 20 rows, processed 250,000 or so, timed out at 10 minutes, and gave up. I would find that useful.