Andreas Karlsson <andreas@proxel.se> writes:
> On 04/27/2014 07:07 PM, Tom Lane wrote:
>> Rewrite timing could easily be captured by EXPLAIN since that call
>> is done within ExplainQuery(). Parse analysis isn't, but we could
>> imagine having transformExplainStmt() time the operation and stick
>> the result into a new field in struct ExplainStmt.
>>
>> I'm not sure if it'd be appropriate to add all of these measurements
>> as separate printout lines; arguably we should just fold them into
>> "planning time".
>>
>> Thoughts?
> I think folding them all (except flex+bison) into Planning time makes
> sense since while the sum total sum is interesting to users you would
> not want every EXPLAIN plan to be filled with timings.
> If it is interesting to print them separately I suggest that is done as
> an option to EXPLAIN, and not by default.
I did a bit of experimentation with a quick-n-dirty prototype and
confirmed the expectation that parse analysis + rewrite is usually
significantly less than planning time. It's not always negligible
by comparison, but it's usually so. So if it weren't for the lock
acquisition issue, it's not clear that it'd be worth accounting for.
A presentation problem that I'm not sure what to do with is that
if the original Query expands to multiple queries during rewrite
(as a result of DO ALSO rules), there will be multiple plan trees
and multiple planning times to display, but we have only one parse
analysis measurement and only one rewrite measurement to offer.
Adding those times into *each* planning time report would clearly
be misleading. We could print them separately (but I agree with
Andreas that this'd mostly be clutter). Or we could add them into
just the first planning-time printout, though that might also be
misleading.
So at this point I'm not entirely sure if this is worth worrying
about, or if we should just leave the existing code alone. But if
we ship 9.4 like this, we probably don't get to change our minds
later.
Comments?
regards, tom lane