>> >> One can use this option as >> postgres=# explain (summary on) select * from pg_class c, pg_type t >> where c.reltype = t.oid; >> QUERY PLAN >> -------------------------------------------------------------------------- >> Hash Join (cost=17.12..35.70 rows=319 width=511) >> Hash Cond: (c.reltype = t.oid) >> -> Seq Scan on pg_class c (cost=0.00..14.19 rows=319 width=259) >> -> Hash (cost=12.61..12.61 rows=361 width=256) >> -> Seq Scan on pg_type t (cost=0.00..12.61 rows=361 width=256) >> Planning time: 48.823 ms >> (6 rows) >> >> When analyze is specified, summary is also set to ON. By default this >> flag is OFF. >> > > I am not sure whether using *summary* to print just planning time is a > good idea. Another option could be SUMMARY_PLAN_TIME.
I have just used the same name as the boolean which controls the printing of planning time. Suggestions are welcome though. We haven't used words with "_" for EXPLAIN options, so I am not sure about SUMMARY_PLAN_TIME. > > + /* Execution time matters only when analyze is requested */ > + if (es->summary && es->analyze) > > Do you really need es->summary in above check? I think es->summary controls printing overall timing, planning as well as execution (hence probably the name "summary"). Earlier it was solely controlled by es->analyze, but now that it's exposed, we do want to check if analyze was also true as without analyze there can not be execution time. So, I changed the earlier condition if (es->summary) to include es->analyze. Can we use only analyze? Probably yes. The question there is why we didn't do it to start with? OR why did we have summary controlling execution time report. Probably the author thought that at some point in future we might separate those two. So, I have left summary there. I don't have problem removing it. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers