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@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
