On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@mit.edu> writes: >> On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> In short then, I think we should just add this to EXPLAIN and be done. >>> -1 for sticking the info into PlannedStmt or anything like that. > >> I'm confused. I thought I was arguing to support your suggestion that >> the initial planning store the time in the cached plan and explain >> should output the time the original planning took. > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
