From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Planning time in explain/explain analyze |
Date: | 2014-01-02 23:08:56 |
Message-ID: | 52C5F188.1010400@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/02/2014 04:08 AM, Robert Haas wrote:
> 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.
Since we support re-planning of prepared statements I would argue the
most useful thing is to print the time it took to fetch the old plan or
the create a new one as the planning time, but I am not a heavy user of
prepared statements.
> 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>
Ok, I will fix this in the next version of the patch.
--
Andreas Karlsson
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2014-01-02 23:09:22 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
Previous Message | Peter Geoghegan | 2014-01-02 22:06:29 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |