Andreas Karlsson <andr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers