To: Simon Riggs <simon@2ndquadrant.com>
cc: Andrew Sullivan <ajs@crankycanuck.ca>, pgsql-performance@postgresql.org
Subject: Re: Some queries starting to hang 
In-reply-to: <1149605576.2621.502.camel@localhost.localdomain> 
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>
Comments: In-reply-to Simon Riggs <simon@2ndquadrant.com>
	message dated "Tue, 06 Jun 2006 15:52:56 +0100"
Date: Tue, 06 Jun 2006 11:06:09 -0400
Message-ID: <17426.1149606369@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Simon Riggs <simon@2ndquadrant.com> writes:
> You mentioned it would be good if the OP had delivered an EXPLAIN
> ANALYZE; I agree(d). The lack of EXPLAIN ANALYZE is frequently because
> you can't get them to run to completion - more so when the query you
> wish to analyze doesn't appear to complete either. 

Well, he could have shown EXPLAIN ANALYZE for the server that was
managing to run the query in a reasonable amount of time.

> The idea I just had was: why do we need EXPLAIN ANALYZE to run to
> completion? In severe cases like this thread, we might be able to
> discover the root cause by a *partial* execution of the plan, as long as
> it was properly instrumented. That way, the OP might have been able to
> discover the root cause himself...

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.

			regards, tom lane