Message-ID: <4485C061.2080206@modgraph-usa.com>
Date: Tue, 06 Jun 2006 10:50:25 -0700
From: "Craig A. James" <cjames@modgraph-usa.com>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Some queries starting to hang
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>
In-Reply-To: <17426.1149606369@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
>>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.

But at least you have some data, which is better than no data.  Even knowing that the plan got stuck on a particular node of the query plan could be vital information.  For a query that never finishes, you can't even find out where it's getting stuck.

That's why Simon's proposal might help in some particularly difficult situations.

Regards,
Craig