From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <rhaas(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Include planning time in EXPLAIN ANALYZE output. |
Date: | 2014-02-03 12:15:32 |
Message-ID: | CA+TgmoY85Kdps6f9W_n105Xpq0apnpJ-=_jMtPBKTRNwTwiORg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Sun, Feb 2, 2014 at 11:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <pg(at)heroku(dot)com> writes:
>> On Wed, Jan 29, 2014 at 1:10 PM, Robert Haas <rhaas(at)postgresql(dot)org> wrote:
>>> Include planning time in EXPLAIN ANALYZE output.
>
>> Isn't it perhaps a little confusing that "Planning time" may well
>> exceed "Total runtime"?
>
> Perhaps s/Total runtime/Execution time/ ?
I'm not really feeling a compelling need to change that. We've been
displaying total runtime - described exactly that way - for many
releases and it's surely is confusing to the novice that the time
reported can be much less than the time reported by psql's \timing
option, usually because of planning time. But adding the planning
time to the output seems to me to make that better, not worse. If the
user can't figure out that runtime != planning time, I'm not sure
they'll be able to figure out execution time != planning time, either.
One of the reasons it's called "Total runtime", or so I've always
assumed, is because it's more inclusive than the time shown for the
root node of the plan tree. Specifically, it includes the time
required to fire triggers.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-02-03 14:14:16 | Re: pgsql: Clean up some sloppy coding in repl_gram.y. |
Previous Message | Tom Lane | 2014-02-02 23:59:47 | pgsql: Switch in psql_scan() must cover all lexer states (except backsl |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2014-02-03 12:22:41 | Re: GIN improvements part2: fast scan |
Previous Message | Christian Kruse | 2014-02-03 11:53:52 | Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire |