Re: So why is EXPLAIN printing only *plan* time?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: So why is EXPLAIN printing only *plan* time?
Date: 2014-04-28 15:36:15
Message-ID: 13317.1398699375@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Apr 27, 2014 at 1:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ... and not, in particular, parse analysis or rewrite time?

> I think breaking those out would be a good idea. Especially rewrite time.

Rewrite time seems generally negligible in comparison to the other two
components, at least in the simple testing I did yesterday. It would
only be significant if you were expanding some complicated views, in
which case planning time would almost surely dominate anyway.

Anyway, I'm starting to come to the conclusion that the idea of silently
adding parse/rewrite time into the "planning time" line isn't such a good
one. So there may or may not be sufficient interest in the other numbers
to justify adding them as separate lines later --- but the key word there
is "later". I now think we should leave "planning time" as it's currently
defined, which means we don't need to address this issue for 9.4.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-04-28 15:44:45 Re: So why is EXPLAIN printing only *plan* time?
Previous Message Andres Freund 2014-04-28 15:33:21 Re: Decrease MAX_BACKENDS to 2^16