Ashutosh,
I realize you were replying to yourself, but you probably didn't need to
include the entire thread below or to top-post.
* Ashutosh Bapat (ashutosh.bapat@enterprisedb.com) wrote:
> 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
> SUMMARY when ON prints planning time. With ANALYZE ON, it also prints
> execution time. When user explicitly uses SUMMARY OFF, it does not
> print planning and execution time (even when ANALYZE is ON). By
> default SUMMARY is ON when ANALYZE is ON, otherwise SUMMARY defaults
> to OFF. Attached explain_summary_examples.out.txt shows examples.
Right, this is how I had been thinking 'summary' would behave.
> 2. explain_exec_timing adds support to print planning time in EXPLAIN
> EXECUTE output with SUMMARY option. In this case, planning time
> includes time required to fetch the plan from cache and plan the query
> if necessary (i.e. after invalidation or the first time it's
> executed.) E.g.
Ok.
diff --git a/doc/src/sgml/ref/explain.sgml b/doc/src/sgml/ref/explain.sgml
[...]
+ Include planning time and execution time. Execution time is included
+ when <literal>ANALYZE</literal> is enabled.
+ It defaults to <literal>TRUE</literal> when <literal>ANALYZE</literal>
+ is enabled. Otherwise it defaults to <literal>FALSE</literal>.
This seems to be part of the concern regarding the naming. I would
reword this along these lines:
Include summary information (eg: totalled timing information) after the
query plan. Summary information is included by default when ANALYZE is
used. Without ANALYZE, summary information is not included by default
but can be enabled using this option.
(that's not great, but hopefully it gets the point across)
The code changes look alright on a cursory look, but we need to hammer
down if we agree on this term or if we need to invent something else.
Thanks!
Stephen
