Martijn van Oosterhout <kleptog@svana.org> writes:
> This is unfortunate because EXPLAIN ANALYZE is an immensly useful tool,
> as far as it goes. I've pondered if some kind of userspace timing
> mechanism could be introduced (possibly using builtin CPU cycle
> counters) to reduce the cost. It does, however, remain a cost.
I wonder if there's a good case for a version of explain analyze that runs the
query and outputs the plan along with row counts but not timing for each row.
You would still be able to see if the estimates are correct. And it would have
basically no overhead so you could use it under a production environment.
> Given that you can see how many times gettimeday() was called, you may
> be able to correct the error. I havn't tried that though.
I tried, it seems like it should be trivial but I got bogged down in details.
Removing profiling overhead is pretty standard for profilers to do though. It
really seems to me like it ought to be done. It still wouldn't let you use
EXPLAIN ANALYZE under production without a lot of overhead though.
--
greg