On 27 April 2014 22:38, Tom Lane Wrote:
> ... and not, in particular, parse analysis or rewrite time?
>
> I'd been a bit suspicious of the recent patch to add $SUBJECT without
> the other pre-execution components, but it just now occurred to me that
> there's at least one reason why this might be a significant omission:
> any delay caused by waiting to acquire locks on the query's tables will
> be spent in the parser.
>
> It's probably okay to omit raw parsing time (that is, flex+bison), even
> though profiling sometimes suggests that that's a nontrivial cost.
> It's completely predictable and more or less linear in the query string
> length, so there are not likely to be any surprises for users in that
> time. But it's not at all clear to me that the same can be said for
> parse analysis or rewrite times.
>
> 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 had understanding that the "Planning time" printed along with EXPLAIN is
only for the purpose to see how much time is spent in creating plan for execution.
If we start including all previous (i.e. parsing + analyzing + rewrite) time also
in "Planning time" then, it might lose whole of the meaning of printing this.
If we add time spent in locking, then "Planning time" for the same query with same statistics
will become variable depending on the amount of time it had to wait to acquire lock, which
will be bit confusing for users.
May be if we really have to print other time (i.e. parsing + analyzing + rewrite), then IMHO
we can print with some different name instead of including in "Planning time" only.
Thanks and Regards,
Kumar Rajeev Rastogi