On Tue, Dec 27, 2016 at 1:27 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > Hi, > We report planning and execution time when EXPLAIN ANALYZE is issued. > We do not have facility to report planning time as part EXPLAIN > output. In order to get the planning time, one has to issue EXPLAIN > ANALYZE which involves executing the plan, which is unnecessary. >
+1. I think getting to know planning time is useful for cases when we are making changes in planner to know if the changes has introduced any regression. > > 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. + /* Execution time matters only when analyze is requested */ + if (es->summary && es->analyze) Do you really need es->summary in above check? We should update documentation of Explain command, but maybe that can wait till we finalize the specs. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
