* Robert Haas (robertmh...@gmail.com) wrote: > Currently the patch includes changes to prepare.c which is what seems > odd to me. I think it'd be fine to say, hey, I can't give you the > planning time in this EXPLAIN ANALYZE because I just used a cached > plan and did not re-plan. But saying, hey, the planning time is > $TINYVALUE, when what we really mean is that looking up the > previously-cached plan took only that long, seems actively misleading > to me.
My thought, at least, was to always grab the planning time and then
provide it for explain and/or explain analyze, and then for re-plan
cases, indicate if a cached plan was returned, if a replan happened, and
if a replan happened, what the old plan time and the new plan time was.
I don't think it makes any sense to report on the time returned from
pulling a previously-cached plan.
I understand that it's not completely free to track the plan time for
every query but I'm in the camp that says "we need better metrics and
information for 99% of what we do" and I'd like to see us eventually
able to track average plan time (maybe on a per-query basis..), average
run-time, how many times we do a hashjoin, mergejoin, the number of
records in/out of each, memory usage, etc, etc.. I don't think we need
per-tuple timing information. I certainly wouldn't want to try and
collect all of this through shared memory or our existing stats
collector.
Thanks,
Stephen
signature.asc
Description: Digital signature
