Re: Reporting planning time with EXPLAIN

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reporting planning time with EXPLAIN
Date: 2017-01-05 04:30:42
Message-ID: CAFjFpRdJeWpOPE041ZxJJPTWX9Rg3CK2CVm+s6AU+OXr_OSMsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 4, 2017 at 8:24 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Ashutosh,
>
> I realize you were replying to yourself, but you probably didn't need to
> include the entire thread below or to top-post.

Sorry, that was unintentional.

>
> * Ashutosh Bapat (ashutosh(dot)bapat(at)enterprisedb(dot)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)

I think it's better than mine which was "overfitting", if we allow
some machine learning terminology here :).

>
> 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.

Agreed. Will wait for consensus.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-01-05 04:33:00 Re: ALTER TABLE parent SET WITHOUT OIDS and the oid column
Previous Message Ashutosh Bapat 2017-01-05 04:19:13 Re: postgres_fdw bug in 9.6