Re: [HACKERS] Reporting planning time with EXPLAIN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Reporting planning time with EXPLAIN
Date
Msg-id 18222.1482938988@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] Reporting planning time with EXPLAIN  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: [HACKERS] Reporting planning time with EXPLAIN  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: [HACKERS] Reporting planning time with EXPLAIN  (Stephen Frost <sfrost@snowman.net>)
Re: [HACKERS] Reporting planning time with EXPLAIN  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Ashutosh Bapat (ashutosh.bapat@enterprisedb.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



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: [HACKERS] Hooks
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] make more use of RoleSpec struct