Date: Tue, 6 Jun 2006 15:51:17 -0500
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: "Craig A. James" <cjames@modgraph-usa.com>,
	pgsql-performance@postgresql.org
Subject: Re: Some queries starting to hang
Message-ID: <20060606205117.GB45331@pervasive.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1149616467.25526.213.camel@state.g2switchworks.com>
User-Agent: Mutt/1.5.11

On Tue, Jun 06, 2006 at 12:54:27PM -0500, Scott Marlowe wrote:
> On Tue, 2006-06-06 at 12:50, Craig A. James wrote:
> > 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.
> 
> Hmmmmm.  I wonder if it be hard to have explain analyze have a timeout
> per node qualifier?  Something that said if it takes more than x
> milliseconds for a node to kill the explain analyze and list the up to
> the nasty node that's using all the time up?
> 
> That would be extremely useful.

Maybe, maybe not. It would be very easy for this to croak on the first
sort it hits. I suspect the original proposal of aborting once a
rowcount estimate proves to be way off is a better idea.

For the record, I also think being able to get a current snapshot is
great, too.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461