Robert Haas <robertmh...@gmail.com> writes: > On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Uh, no, wasn't my suggestion. Doesn't that design imply measuring *every* >> planning cycle, explain or no? I was thinking more of just putting the >> timing calls into explain.c.
> 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. Meh. Why? This would only come into play for EXPLAIN EXECUTE stmtname. I don't think users would be surprised to see a report of minimal planning time for that. In fact, it might be a good thing, as it would make it easier to tell the difference between whether you were seeing a generic plan or a custom plan for the prepared statement. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers