Re: That EXPLAIN ANALYZE patch still needs work

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 18:53:28
Message-ID: 87mzcmgnyv.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Are we still going to subtract out the gettimeofday overhead?
>
> > I was always more excited about that than the sampling aspect. I've run into
> > queries where EXPLAIN ANALYZE results were deceptive due to the gettimeofday
> > overhead but I've never run into a query where gettimeofday overhead made
> > running the query under EXPLAIN ANALYZE impractical.
>
> That would be deceptive in a different way, ie, make it look like there
> was a whole bunch of outside-the-plan overhead.

Well that's exactly what there is.

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.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-09 19:02:50 Re: That EXPLAIN ANALYZE patch still needs work
Previous Message Greg Stark 2006-06-09 18:50:41 Re: ADD/DROP constraints