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