Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN
Date
Msg-id 1149799121.9225.7.camel@localhost.localdomain
Whole thread Raw
In response to Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 2006-06-08 at 13:51 -0400, Tom Lane wrote:
> I wrote:
> > Simon Riggs <simon@2ndquadrant.com> writes:
> >> A full EXPLAIN ANALYZE is always desirable - we agree on that. The
> >> question is what we do when one is not available.
> 
> > The least bad alternative I've heard is to let EXPLAIN ANALYZE print
> > out stats-so-far if the query is canceled by control-C or statement
> > timeout.  The objection to this is you may mistake startup transients
> > for full query behavior ... but at least the numbers will be good as
> > far as they go.
> 
> I thought some more about this

Thanks.

> So it seems we need a way to stop the query 

If we were able to stream results back to the client, then EA would be
simply a meta-query, emitting a stream of explain text tuples, rather
than result tuples. No further need for stopping the query to return
intermediate results.

If we did this say every minute, rather than on interrupt, you'd be
getting close to being able to build that "progress bar" that people
have been mentioning - I'd not really thought that was possible until
now. Would allow us to build a pg_top that would show the current EA
results for a query as it executes.

--  Simon Riggs EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: PG 8.2
Next
From: Greg Stark
Date:
Subject: Re: ADD/DROP INHERITS