Re: Planning time in explain/explain analyze - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Planning time in explain/explain analyze
Date
Msg-id 18065.1389645625@sss.pgh.pa.us
Whole thread Raw
In response to Re: Planning time in explain/explain analyze  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Planning time in explain/explain analyze  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 13, 2014 at 3:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Meh.  Why?  This would only come into play for EXPLAIN EXECUTE stmtname.
>> I don't think users would be surprised to see a report of minimal planning
>> time for that.  In fact, it might be a good thing, as it would make it
>> easier to tell the difference between whether you were seeing a generic
>> plan or a custom plan for the prepared statement.

> It would also make it easier to be wrong.  If you want to display that
> information explicitly, fine.  But asking the user to use the elapsed
> time to guess whether or not we really planned anything is just going
> to confuse people who don't have enough experience with the system to
> know what the boundary is between the largest time that could be a
> cache lookup and the smallest time that could be real planning
> activity.  And that means virtually everyone, me included.

If you're saying that you'd like EXPLAIN to explicitly mention whether
the plan was cached or custom, I don't have any great complaint about
that.  I'm just not seeing how you arrive at the conclusion that we
mustn't report the amount of time EXPLAIN spent to get the plan.
If we do what you're proposing we'll just have a different set of confused
users, who will be wondering how EXPLAIN could have managed to spend
100 msec planning something when the EXPLAIN only took 10 msec in toto
according to psql.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Linux kernel impact on PostgreSQL performance
Next
From: Robert Haas
Date:
Subject: Re: Performance Improvement by reducing WAL for Update Operation