So why is EXPLAIN printing only *plan* time?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: So why is EXPLAIN printing only *plan* time?
Date: 2014-04-27 17:07:49
Message-ID: 20458.1398618469@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2014-04-27 17:31:14 Re: So why is EXPLAIN printing only *plan* time?
Previous Message Tom Lane 2014-04-27 16:18:58 Re: includedir_internal headers are not self-contained