* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > >> 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.
Using 'summary' seems entirely reasonable to me, I don't think we need to complicate it by saying 'summary_plan_time'- I know that I'd had to have to write that out. > > + /* Execution time matters only when analyze is requested */ > > + if (es->summary && es->analyze) > > > > Do you really need es->summary in above check? I'm pretty sure we do. EXPLAIN (ANALYZE, SUMMARY OFF) Should not print the summary (which means it shouldn't print either the planning or execution time). > I think es->summary controls printing overall timing, planning as well > as execution (hence probably the name "summary"). I am imagining it controlling if we print the summary or not, where the summary today is the last two lines: Planning time: 14.020 ms Execution time: 79.555 ms Thanks! Stephen
signature.asc
Description: Digital signature
