Re: Planning time in explain/explain analyze

Andreas, Robert,

* Andreas Karlsson (andreas(at)proxel(dot)se) wrote:
> A patch with updated documentation is attached.

Thanks for working on this!

> 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.

Agreed, and really, it'd be nice to know *both*. If we're worried about
the timing cost when going through a no-op GetCachedPlan(), then perhaps
we don't add that, but if we actually *do* re-plan, it'd be handy to
know that and to know the timing it took.

> >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.

Agreed.

> 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.

This is perhaps the biggest point against- if we keep it this way...

> 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.

The slow-clock argument is really quite frustrating for those of us who
are looking to add more and more metrics to PG. We're nowhere near the
level that we need to be and it shows (particularly for users coming
from $OTHER-RDBMS). Perhaps we should try and come up with a solution
to address those cases (turn off metrics ala turning off stats?) while
not preventing us from gathering metrics on more reasonable systems.

Thanks,

Stephen