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-09 04:48:42 |
Message-ID: | 52CE2A2A.4040309@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
A patch with updated documentation is attached.
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.
>
> 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.
A possible argument against printing the time to create the plan is that
unless it was created when running EXPLAIN we will not know it. I do not
think we want to always measure the time it took to generate a plan due
to slow clocks on some architectures. Also I feel that such a patch
would be more invasive.
Just my reasoning for the current solution. I welcome any opinions about
how to print planning time for prepared statements since I am not a
heavy user of them.
--
Andreas Karlsson
Attachment | Content-Type | Size |
---|---|---|
explainplantime-v3.diff | text/x-patch | 15.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-01-09 06:02:32 | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier |
Previous Message | Robert Treat | 2014-01-09 04:09:01 | Re: Standalone synchronous master |