Re: Planning time in explain/explain analyze
От | Andreas Karlsson |
---|---|
Тема | Re: Planning time in explain/explain analyze |
Дата | |
Msg-id | 52CE2A2A.4040309@proxel.se обсуждение исходный текст |
Ответ на | Re: Planning time in explain/explain analyze (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Planning time in explain/explain analyze
|
Список | pgsql-hackers |
A patch with updated documentation is attached. On 01/02/2014 04:08 AM, Robert Haas wrote: > I'm wondering whether the time should be stored inside the PlannedStmt > node instead of passing it around separately. One possible problem > with the way you've done things here is that, in the case of a > prepared statement, EXPLAIN ANALYZE will emit the time needed to call > GetCachedPlan(), even if that function didn't do any replanning. Now > you could argue that this is the correct behavior, but I think there's > a decent argument that what we ought to show there is the amount of > time that was required to create the plan that we're displaying at the > time it was created, rather than the amount of time that was required > to figure out that we didn't need to replan. > > A minor side benefit of this approach is that you wouldn't need to > change the signature for ExplainOnePlan(), which would avoid breaking > extensions that may call it. A possible argument against printing the time to create the plan is that unless it was created when running EXPLAIN we will not know it. I do not think we want to always measure the time it took to generate a plan due to slow clocks on some architectures. Also I feel that such a patch would be more invasive. Just my reasoning for the current solution. I welcome any opinions about how to print planning time for prepared statements since I am not a heavy user of them. -- Andreas Karlsson
Вложения
В списке pgsql-hackers по дате отправления: