Re: Auto-explain patch

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!

In response to

Browse pgsql-hackers by date

  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