Re: [HACKERS] Reporting planning time with EXPLAIN

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Reporting planning time with EXPLAIN
Дата
Msg-id 18222.1482938988@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [HACKERS] Reporting planning time with EXPLAIN  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: [HACKERS] Hooks
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] make more use of RoleSpec struct