Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN
Date: 2006-06-08 20:38:41
Message-ID: 1149799121.9225.7.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2006-06-08 at 13:51 -0400, Tom Lane wrote:
> I wrote:
> > Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2006-06-08 20:42:17 Re: ADD/DROP INHERITS
Previous Message Jim C. Nasby 2006-06-08 20:34:04 Re: PG 8.2