Re: That EXPLAIN ANALYZE patch still needs work - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: That EXPLAIN ANALYZE patch still needs work
Date
Msg-id 1149869667.2691.321.camel@localhost.localdomain
Whole thread Raw
In response to Re: That EXPLAIN ANALYZE patch still needs work  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2006-06-09 at 10:56 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > I propose we revert the sampling patch (sorry Martijn)
> 
> yah ...
> 
> > and go with the
> > patch to have an explain_analyze_timing parameter (default=on).
> 
> This I'm unexcited about.  EXPLAIN output isn't all that transparent
> anyway, and losing the extra cue of seeing where the time is really
> going would make it extremely easy for people to misinterpret their
> problems.

As before, agreed, but it works and is available now.

> I was intending to push forward with the idea of being able to get
> numbers out of a canceled EXPLAIN.  That will allow you to get some
> information even when the underlying query runs longer than you're
> willing to tolerate.  I still say that the number of queries where
> avoiding gettimeofday overhead would transform an intolerable runtime
> into a tolerable one is pretty limited.

That would be a good feature to have.

> The other thing that I think would be worth investigating is
> timer-driven sampling, although it's not yet clear whether we can
> make that work usefully.  Anyone want to take up that project?

Not me, sorry.

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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Proposal for debugging of server-side stored procedures
Next
From: Tom Lane
Date:
Subject: Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)