Re: Planning time in explain/explain analyze

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planning time in explain/explain analyze
Date: 2014-01-02 03:08:48
Message-ID: CA+TgmoaBg7u_9m_cnjRX15b1=6faHTF0jJAMnw_3Fd5PVhwdpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Dec 28, 2013 at 11:32 PM, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
> New version of the patch with updated documentation and which does not
> display the planning time when the COSTS are off.
>
> I will add it to the next commitfest.

I'm wondering whether the time should be stored inside the PlannedStmt
node instead of passing it around separately. One possible problem
with the way you've done things here is that, in the case of a
prepared statement, EXPLAIN ANALYZE will emit the time needed to call
GetCachedPlan(), even if that function didn't do any replanning. Now
you could argue that this is the correct behavior, but I think there's
a decent argument that what we ought to show there is the amount of
time that was required to create the plan that we're displaying at the
time it was created, rather than the amount of time that was required
to figure out that we didn't need to replan.

A minor side benefit of this approach is that you wouldn't need to
change the signature for ExplainOnePlan(), which would avoid breaking
extensions that may call it.

Also, I am inclined to think we ought to update the examples, rather
than say this:

+ rewriting and parsing. We will not include this line in later examples in
+ this section.
+ </para>

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2014-01-02 03:14:43 more psprintf() use
Previous Message Robert Haas 2014-01-02 02:37:25 Re: Bogus error handling in pg_upgrade