On Mon, Jan 13, 2014 at 3:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane <tgl@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.
It would also make it easier to be wrong. If you want to display that
information explicitly, fine. But asking the user to use the elapsed
time to guess whether or not we really planned anything is just going
to confuse people who don't have enough experience with the system to
know what the boundary is between the largest time that could be a
cache lookup and the smallest time that could be real planning
activity. And that means virtually everyone, me included.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
