From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, 'Alvaro Herrera' <alvherre(at)commandprompt(dot)com>, 'Martijn van Oosterhout' <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: That EXPLAIN ANALYZE patch still needs work |
Date: | 2006-06-09 16:14:27 |
Message-ID: | 1149869667.2691.321.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2006-06-09 at 10:56 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-09 16:18:35 | Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work) |
Previous Message | Andrew Dunstan | 2006-06-09 16:01:11 | Re: Proposal for debugging of server-side stored procedures |