Re: Planning time in explain/explain analyze

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Planning time in explain/explain analyze
Дата
Msg-id 18065.1389645625@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Planning time in explain/explain analyze  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Planning time in explain/explain analyze  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Linux kernel impact on PostgreSQL performance
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Performance Improvement by reducing WAL for Update Operation