| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> | 
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgreSQL(dot)org | 
| Subject: | Re: That EXPLAIN ANALYZE patch still needs work | 
| Date: | 2006-06-07 15:34:30 | 
| Message-ID: | 358.1149694470@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Martijn van Oosterhout <kleptog(at)svana(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-06-07 15:45:17 | Re: self-deadlock at FATAL exit of boostrap process on read error | 
| Previous Message | Martijn van Oosterhout | 2006-06-07 15:17:12 | Re: That EXPLAIN ANALYZE patch still needs work |