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
