Re: Auto-explain patch
От | Gregory Stark |
---|---|
Тема | Re: Auto-explain patch |
Дата | |
Msg-id | 874p6ydotf.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Auto-explain patch (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
"Simon Riggs" <simon@2ndquadrant.com> writes: > On Wed, 2008-07-09 at 09:11 +0000, Dean Rasheed wrote: >> >> So I suggest grouping these parameters in their own category >> (eg. "sql_trace") and then having additional parameters to control >> where the output would go. So the sql_trace parameters would be: >> >> * sql_trace_min_planner_duration >> * sql_trace_min_executor_duration >> * sql_trace_explain_plan >> > If its possible to do the sql_trace_* parameters as a single one, I > would prefer it, since it makes it more practical to use dynamically. > Not sure how...maybe with a wrapper function? > > sql_trace(integer) sets just sql_trace_min_executor_duration > sql_trace(integer, boolean) sets executor and explain > sql_trace(integer, integer, boolean) sets all 3 Fwiw it seems to me "trace_sql_*" would be nicer, much as we have track_* guc parameters. Though I also wonder if there's really any distinction here between "tracing" and "logging" like log_explain_plan and so on. Perhaps we should keep the word "trace" for a more in-detail facility. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
В списке pgsql-hackers по дате отправления: