From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Dean Rasheed" <dean_rasheed(at)hotmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Auto-explain patch |
Date: | 2008-07-10 10:19:08 |
Message-ID: | 874p6ydotf.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)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!
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Urbański | 2008-07-10 10:30:44 | Re: Security and Data Protection Issues |
Previous Message | Simon Riggs | 2008-07-10 09:48:42 | Re: Auto-explain patch |