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

From Tom Lane
Subject Re: That EXPLAIN ANALYZE patch still needs work
Date
Msg-id 358.1149694470@sss.pgh.pa.us
Whole thread Raw
In response to Re: That EXPLAIN ANALYZE patch still needs work  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: That EXPLAIN ANALYZE patch still needs work  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Wed, Jun 07, 2006 at 09:53:32AM -0400, Tom Lane wrote:
>> If we do have to revert, I'd propose that we pursue the notion of
>> interrupt-driven sampling like gprof uses.

> How would that work? You could then estimate how much time was spent in
> each node, but you no longer have any idea about when they were entered
> or left.

Hm?  It would work the same way gprof works.  I'm imagining something
along the lines of

global variable:volatile Instrumentation *current_instr = NULL;

also add an "Instrumentation *parent_instr" field to Instrumentation

InstrStartNode does:instr->parent_instr = current_instr;current_instr = instr;

InstrStopNode restores the previous value of the global:current_instr = instr->parent_instr;

timer interrupt routine does this once every few milliseconds:total_samples++;for (instr = current_instr; instr; instr
=instr->parent_instr)    instr->samples++;
 

You still count executions and tuples in InstrStartNode/InstrStopNode,
but you never call gettimeofday there.  You *do* call gettimeofday at
beginning and end of the whole query to measure the total runtime,
and then you blame a fraction samples/total_samples of that on each
node.

The bubble-up of sample counts to parent nodes could perhaps be done
while printing the results instead of on-the-fly as sketched above, but
the above seems simpler.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: That EXPLAIN ANALYZE patch still needs work
Next
From: Tom Lane
Date:
Subject: Re: self-deadlock at FATAL exit of boostrap process on read error