Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > To avoid user confusion it would reasonable to print out a line at the > > bottom: > > > Explain analyze profiling overhead removed: xxx ms > > > That also gives the user feedback on how precise their explain analyze > > results > > are. If they see that the overhead being removed is as large as the timing > > remaining then they can realize that the results aren't especially precise. > > On > > the other hand if they see that the overhead being removed is small then > > they > > can be pretty confident in the precision of the results. > > I would prefer to leave the numbers unmanipulated, because frankly I'd > have no confidence in the correction. Perhaps we could put a note at the > bottom about "Estimated total profiling overhead: xxx ms".
Well the whole reason the overhead is deceptive is that some nodes call gettimeofday many more times proportionally to their running time than others. It makes users suspect cpu-intensive nodes that process many records when the real problem lies in a i/o-intensive node that processes few records. Just showing the total overhead will give the user the impression that time is distributed evenly throughout the nodes proportionally to their total time which doesn't help correct the distortion. There seem to be two types of overhead going on. There's the amount of time spent in gettimeofday itself which is pretty consistent. Then there's other effects that cause normal operation itself to take longer (or potentially even less long). Postgres may as well remove the consistent gettimeofday overhead it can identify and measure even if there's more it can't characterize perfectly. -- greg ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match