Re: EXPLAIN ANALYZE - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: EXPLAIN ANALYZE
Date
Msg-id 20061213194646.GL6551@nasby.net
Whole thread Raw
In response to Re: EXPLAIN ANALYZE  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: EXPLAIN ANALYZE  (Joshua Reich <josh@root.net>)
List pgsql-hackers
On Mon, Dec 11, 2006 at 12:24:12AM +0100, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > Well, I'd like a way of making EXPLAIN ANALYZE return something
> > useful within a reasonable amount of time. We can define that as the
> > amount of time that the user considers is their goal for the query.
> 
> What sort of "useful" results would you expect to be able to see from 
> such an aborted EXPLAIN ANALYZE?  I cannot quite imagine what 
> instructive value a partially executed plan output would have.  It's 
> not like we can somehow ensure executing an equal proportion of each 
> plan node or something.  Do you have a specific case in mind?

The query is most likely to get canceled while it is working on whatever
node in the plan is the bottleneck, and it's likely going to be easy to
spot since nodes above it wouldn't have gotten much done.
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: pg_standby and build farm
Next
From: "Simon Riggs"
Date:
Subject: Re: recovery.conf parsing problems