Re: That EXPLAIN ANALYZE patch still needs work
От | Tom Lane |
---|---|
Тема | Re: That EXPLAIN ANALYZE patch still needs work |
Дата | |
Msg-id | 358.1149694470@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: That EXPLAIN ANALYZE patch still needs work (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: That EXPLAIN ANALYZE patch still needs work
|
Список | 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 по дате отправления: