Re: Reporting planning time with EXPLAIN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, 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: 2016-12-28 15:29:48
Message-ID: 18222.1482938988@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Ashutosh Bapat (ashutosh(dot)bapat(at)enterprisedb(dot)com) wrote:
>>> I am not sure whether using *summary* to print just planning time is a
>>> good idea. Another option could be SUMMARY_PLAN_TIME.

> Using 'summary' seems entirely reasonable to me,

I think it's an awful choice of name; it has nothing to do with either
the functionality or the printed name of the field. And I could imagine
future uses of "summary" to mean something much different, like say an
actual summary. (The dictionary meaning of "summary" is "a brief
restatement of the main points of something"; adding new information
is not even approximately within the meaning.)

How about just saying that the existing TIMING option turns this on,
if it's specified without ANALYZE? Right now that combination draws
an error:

regression=# explain (timing on) select 1;
ERROR: EXPLAIN option TIMING requires ANALYZE

so there's no existing usage that this would break.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-12-28 15:33:56 Re: make more use of RoleSpec struct
Previous Message David Fetter 2016-12-28 15:25:00 Re: Hooks