auto_explain contrib moudle

Ooops. That last patch had an embarrassing little typo which caused it to not
actually record the planner times.

This new version fixes that and also includes a little patch to psql so that it
ignores any backend notices during tab-completion, which otherwise just get
in the way. Trace during tab-completion still goes to the server log, if enabled,
since this might actually be useful for debugging psql.

> * trace_min_planner_duration - int, PGC_USERSET
> * trace_min_executor_duration - int, PGC_USERSET
> * trace_explain_plan - bool, PGC_USERSET
>

I'm toying with the idea of adding another parameter, just for convenience:

* auto_trace = on | off

If trace_min_planner_duration and trace_min_executor_duration are both -1,
then setting auto_trace=on would be equivalent to setting
trace_min_planner_duration=0, trace_min_executor_duration=0 and
trace_explain_plan=on, causing *all* statements to be timed and explained
(similar to Oracle's AUTOTRACE).

If either of trace_min_planner_duration or trace_min_executor_duration
are> -1, then auto_trace will do nothing, and only those queries that are
slow to plan and/or execute would be logged.

I'll hold off actually do any more with this for now though, because I feel
that there are still a couple of questions not fully answered:

* Is a whole new logging level (TRACE) overkill for this, or would it
potentially have other uses in the future? My feeling is that it works quite
nicely.

* It it safe to open this up to ordinary users, or do more restrictions need
to be put on it, and if so what?

Regards, Dean

_________________________________________________________________
The John Lewis Clearance - save up to 50% with FREE delivery
http://clk.atdmt.com/UKM/go/101719806/direct/01/

On Fri, 2008-07-11 at 09:33 +0000, Dean Rasheed wrote:

> This new version

Thanks, I'll review this next week now.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Dean Rasheed <dean_rasheed(at)hotmail(dot)com> writes:
> This new version fixes that and also includes a little patch to psql so that it
> ignores any backend notices during tab-completion, which otherwise just get
> in the way. Trace during tab-completion still goes to the server log, if enabled,
> since this might actually be useful for debugging psql.

Comments:

I do not think that you should invent a new elog level for this, and
especially not one that is designed to send unexpected messages to the
client. Having to kluge tab completion like that is just a signal that
you're going to break a lot of other clients too. It seems to me that
the right behavior for auto-explain messages is to go only to the log by
default, which means that LOG is already a perfectly good elog level for
auto-explain messages.

Drop the query_string addition to PlannedStmt --- there are other ways
you can get that string in CVS HEAD. I don't think that planner_time
belongs there either. It would be impossible to define a principled way
to compare two PlannedStmts for equality with that in there. Nor do I
see the point of doing it the way you're doing it. Why don't you just
log the slow planning cycle immediately upon detecting it in planner()?
I don't see that a slow planning cycle has anything necessarily to do
with a slow execution cycle, so IMHO they ought to just get logged
independently.

Please do not export ExplainState --- that's an internal matter for
explain.c. Export some wrapper function with a cleaner API than
explain_outNode, instead.

regards, tom lane

Thanks for the feedback, and sorry for my delay in replying (I was on
holiday).

> Tom Lane wrote:
>
> Comments:
>
> I do not think that you should invent a new elog level for this, and
> especially not one that is designed to send unexpected messages to the
> client. Having to kluge tab completion like that is just a signal that
> you're going to break a lot of other clients too. It seems to me that
> the right behavior for auto-explain messages is to go only to the log by
> default, which means that LOG is already a perfectly good elog level for
> auto-explain messages.

The more I thought about this, the more I thought that it was OTT to
add a new elog level just for this, so I agree it should probably just
go to the LOG elog level.

I don't agree with your reasoning on tab-completion though. I actually
think that this is a signal of a broken client. If the user sets
client_min_messages to LOG or lower, and has any of the other logging
or debugging parameters enabled, the output tramples all over the
suggested completions. I don't think the average user is interested in
log/debug output from the queries psql does internally during
tab-completion. So IMHO the tab-completion 'kludge', is still
worthwhile, regardless of the rest of the patch.

> Drop the query_string addition to PlannedStmt --- there are other ways
> you can get that string in CVS HEAD.

OK. What is the best way to get this string now? Are you referring to
debug_query_string, or is there another way?

> I don't think that planner_time
> belongs there either. It would be impossible to define a principled way
> to compare two PlannedStmts for equality with that in there. Nor do I
> see the point of doing it the way you're doing it. Why don't you just
> log the slow planning cycle immediately upon detecting it in planner()?
> I don't see that a slow planning cycle has anything necessarily to do
> with a slow execution cycle, so IMHO they ought to just get logged
> independently.

Makes sense.

> Please do not export ExplainState --- that's an internal matter for
> explain.c. Export some wrapper function with a cleaner API than
> explain_outNode, instead.
>
> regards, tom lane

OK, that's much neater.

I'll try to rework this ASAP but I understand if it's too late for
this commitfest.

Cheers, Dean.

_________________________________________________________________
Win a voice over part with Kung Fu Panda & Live Search   and   100’s of Kung Fu Panda prizes to win with Live Search
http://clk.atdmt.com/UKM/go/107571439/direct/01/

Hi,

I'm very interested in the auto-explain feature.
Are there any plans to re-add it in the next commit-fest?

Dean Rasheed <dean_rasheed(at)hotmail(dot)com> wrote:

> > Please do not export ExplainState --- that's an internal matter for
> > explain.c. Export some wrapper function with a cleaner API than
> > explain_outNode, instead.
>
> OK, that's much neater.

How about the attached patch?
I exported initialization of ExplainState and explain_outNode call
to a new function ExplainOneResult. It receives executor nodes and
returns the tree as a text.

I think it'd be better to implement the auto-explain feature
not as a core feature but as an extension, because various users
have various desires about the feature. We could write a small extension
moudle using hooks and the ExplainOneResult function. If we includes
the extension as a contrib module, users can mofify it and install
customized version of auto-explain.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

On Tue, 2008-08-26 at 19:24 +0900, ITAGAKI Takahiro wrote:

> I'm very interested in the auto-explain feature.

Me too, though must apologise I've had no further time to review this.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Here is a contrib version of auto-explain.
I'd like to add it the next commit-fest in September.

I set a high value on logging, not on interactive responce because
I think it's enough if we use EXPLAIN ANALYZE directly in psql or
set min_client_messages to LOG.

The module consists of one contrib directory and three patches:

* export_explain.patch
It exports an internal routine in explain.c as ExplainOneResult().
Auto-explain module requires it.

* custom_guc_flags.patch
It enables to use guc flags in custom guc variables.
Auto-explain module works better with it because there is a millisecond
unit variable (explain.log_min_duration) in the module.

* psql_ignore_notices.patch
It suppress notice messages during psql tab-completion and
\d commands. I extracted it from Dean's patch.
Auto-explain module does not always need the patch, but I think
this feature is useful even if we don't use auto-explain.
psql will ignore annoying messages on non-user SQLs when we set
min_client_messages to lower level and enable some of log_* or
debug_* options.

* auto_explain.tgz
A contrib module version of auto-explain.
An arguable part is initializing instruments in ExecutorRun_hook.
The initialization should be done in ExecutorStart normally, but
it is too late in the hook. Is it safe? or are there any better idea?
README is a plain-text for now, and I'll rewrite it in sgml if needed.

Comments welcome.

(Here is a copy of README)

auto_explain
------------
Log query plans that execution times are longer than configuration.

Usage
-----
#= LOAD 'auto_explain';
#= SET explain.log_min_duration = 0;
#= SET explain.log_analyze = true;
#= SELECT count(*)
FROM pg_class, pg_index
WHERE oid = indrelid AND indisunique;

LOG: duration: 0.457 ms plan:
Aggregate (cost=14.90..14.91 rows=1 width=0) (actual time=0.444..0.445 rows=1 loops=1)
-> Hash Join (cost=3.91..14.70 rows=81 width=0) (actual time=0.147..0.402 rows=81 loops=1)
Hash Cond: (pg_class.oid = pg_index.indrelid)
-> Seq Scan on pg_class (cost=0.00..8.27 rows=227 width=4) (actual time=0.011..0.135 rows=227 loops=1)
-> Hash (cost=2.90..2.90 rows=81 width=4) (actual time=0.104..0.104 rows=81 loops=1)
-> Seq Scan on pg_index (cost=0.00..2.90 rows=81 width=4) (actual time=0.008..0.056 rows=81 loops=1)
Filter: indisunique
STATEMENT: SELECT count(*)
FROM pg_class, pg_index
WHERE oid = indrelid AND indisunique;

GUC variables
-------------
* explain.log_min_duration (= -1)
Sets the minimum execution time above which plans will be logged.
Zero prints all plans. -1 turns this feature off.

* explain.log_analyze (= false)
Use EXPLAIN ANALYZE for plan logging.

* explain.log_verbose (= false)
Use EXPLAIN VERBOSE for plan logging.

You can use shared_preload_libraries or local_preload_libraries to
load the module automatically. If you do so, you also need to add
"explain" in custom_variable_classes and define explain.* variables
in your postgresql.conf.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

> Here is a contrib version of auto-explain.

OK, I hadn't considered doing it as a module before.

Is it only available to superusers? Do we have a general policy on
this? Most logging options are superuser-only, but the recent changes
to LOG debug_print_* output have left them PGC_USERSET.

Regards, Dean.

_________________________________________________________________
Win a voice over part with Kung Fu Panda & Live Search   and   100’s of Kung Fu Panda prizes to win with Live Search
http://clk.atdmt.com/UKM/go/107571439/direct/01/

Dean Rasheed <dean_rasheed(at)hotmail(dot)com> wrote:

> Is it only available to superusers?

Presently, yes.

> Do we have a general policy on
> this? Most logging options are superuser-only, but the recent changes
> to LOG debug_print_* output have left them PGC_USERSET.

I set it PGC_SUSET because other log_* options have PGC_SUSET.
I'm not sure what is the difference between log_* and debug_* ...

I think the best policy is to allow general users only to turn "on"
those options, but not to turn "off" if the default setting is on.
We might need to get default values in postgresq.conf in the context
of assignment.

Here is a psesudo code. Is it possible?

bool log_xxx_assign_hook(newval, source)
{
if (by SET command && !superuser())
{
if (default_value == true && newval == false)
elog(ERROR, "You cannot turn off the loggging option");
}
return true; /* ok, you can reset it */
}

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

> * auto_explain.tgz
> A contrib module version of auto-explain.
> An arguable part is initializing instruments in ExecutorRun_hook.
> The initialization should be done in ExecutorStart normally, but
> it is too late in the hook. Is it safe? or are there any better idea?
> README is a plain-text for now, and I'll rewrite it in sgml if needed.
>

How about adding a new hook to control instrumentation of queries in
ExecutorStart? Something like:

typedef bool (*ExecutorDoInstrument_hook_type) (QueryDesc *queryDesc, int eflags);

extern PGDLLIMPORT ExecutorDoInstrument_hook_type ExecutorDoInstrument_hook;

I think that would allow your module code to be simplified,
and it would allow other future extensions to hook in and
enable instrumentation before queries are run.

Regards, Dean.

_________________________________________________________________
Win a voice over part with Kung Fu Panda & Live Search   and   100’s of Kung Fu Panda prizes to win with Live Search
http://clk.atdmt.com/UKM/go/107571439/direct/01/

Dean Rasheed <dean_rasheed(at)hotmail(dot)com> wrote:

> > An arguable part is initializing instruments in ExecutorRun_hook.
> > The initialization should be done in ExecutorStart normally, but
> > it is too late in the hook. Is it safe? or are there any better idea?
>
> How about adding a new hook to control instrumentation of queries in
> ExecutorStart? Something like:
>
> typedef bool (*ExecutorDoInstrument_hook_type) (QueryDesc *queryDesc, int eflags);
> extern PGDLLIMPORT ExecutorDoInstrument_hook_type ExecutorDoInstrument_hook;

I think it is not good to have any single-purpose hooks -- a new global
variable "bool force_instrument" would be enough for the purpose ;-)

I'd like to suggest on-demand allocation of instruments instead.
PlanState->instrument is not only a runtime statstics collector, but also
represents whether instrumentation is enabled or not. However, we also
have the same information in EState->es_insrument. If we use it instread
of NULL check, we could initialize instrument fields in executor.

[src/backend/executor/execProcnode.c]
ExecProcNode(PlanState *node)
{
...
if (node->state->es_instrument)
{
if (node->instrument == NULL)
node->instrument = InstrAlloc(1, long_lived_memory_context);
InstrStartNode(node->instrument);
}

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

On 8/28/08, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> Here is a contrib version of auto-explain.

> You can use shared_preload_libraries or local_preload_libraries to
> load the module automatically. If you do so, you also need to add
> "explain" in custom_variable_classes and define explain.* variables
> in your postgresql.conf.

Is it possible to use LOAD command to load the module?

--
marko

"Marko Kreen" <markokr(at)gmail(dot)com> wrote:

> On 8/28/08, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> > You can use shared_preload_libraries or local_preload_libraries to
> > load the module automatically. If you do so, you also need to add
> > "explain" in custom_variable_classes and define explain.* variables
> > in your postgresql.conf.
>
> Is it possible to use LOAD command to load the module?

Yes, but disabled in default.
You need to enable it like:

LOAD 'auto_explain';
SET explain.log_min_duration = '100ms';
SET explain.log_analyze = true;
SELECT ...

In that case, you don't need to define custom_variable_classes.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

On 9/2/08, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> "Marko Kreen" <markokr(at)gmail(dot)com> wrote:
> > On 8/28/08, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> > > You can use shared_preload_libraries or local_preload_libraries to
> > > load the module automatically. If you do so, you also need to add
> > > "explain" in custom_variable_classes and define explain.* variables
> > > in your postgresql.conf.
> >
> > Is it possible to use LOAD command to load the module?
>
> Yes, but disabled in default.
> You need to enable it like:
>
> LOAD 'auto_explain';
> SET explain.log_min_duration = '100ms';
>
> SET explain.log_analyze = true;
>
> SELECT ...
>
> In that case, you don't need to define custom_variable_classes.

I was interested if it is possible to enable it for single session.
Seems it is. Good.

--
marko

On Wed, Aug 27, 2008 at 8:54 PM, ITAGAKI Takahiro
<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> Here is a contrib version of auto-explain.
> I'd like to add it the next commit-fest in September.

Here is my review:

*custom_guc_flags-0828.patch

It seems to be windows newline damaged? lots of ^M at the end of the
lines, could not get it to apply cleanly. New patch attached.

My only other concern is the changes to DefineCustom*() to tag the new
flags param. Now I think anyone who uses Custom gucs will want/should
be able to set that. I did not see any people in contrib using it but
did not look on PGfoundry. Do we need to document the change
somewhere for people who might be using it???

*export_explain.patch:

This looks much better than the old exporting of ExplainState way and
fixes tom's complaint about exporting ExplainState, so looks good to
me.

*psql_ignore_notices-0828.patch:

This is not needed anymore because we log to LOG. (as you pointed out)
Tom also voiced some concern about this possibly breaking (or broken) clients.

I set my client_min_messages to notice and tried tab completing common
things I do.. I did not see any NOTICES, so unless we have an annoying
message someone knows about (and maybe it should not be a notice
then). I think this should get dropped.

*auto_explalin.c:

init_instrument()

Hrm this strikes me as kind of kludgy... Any thoughts on the 4 cases
in the switch getting out of sync (T_AppendState, T_BitmapAndState,
T_BitmapOrState, T_SubqueryScanState)? The only "cleaner" way I can
see is to add a hook for CreateQueryDesc so we can overload
doInstrument and ExecInitNode will InstrAlloc them all for us.
I dunno Suggestions??

use the {outer|inner}PlanState macros instead of ->lefttree, ->righttree

can probably save a few cycles by wrapping those in a
if (outerPlanNode(planstate))

A quick check shows they can be null, but maybe they never can be when
they get to this point... So maybe thats a mute point.

If this sticks around I would suggest restructuring it to better match
explain_outNode so its easier to match up
something like...

if (planstate->initPlan)
foreach...
init_instrument()

if (outerPlanState())
foreach...

if (innerPlanState())

the only other comment I have is suset_assign() do we really need to
be a superuser if its all going to LOG ? There was some concern about
explaining security definer functions right? but surely a regular
explain on those shows the same thing as this explain? Or what am I
missing?

and obviously your self noted comment that README.txt should be sgml

Thanks for your reviewing, Alex.
I applied your comments to my patch.

- auto_explain.patch : patch against HEAD
- auto_explain.tgz : contrib module
- autoexplain.sgml : documentation

"Alex Hunsaker" <badalex(at)gmail(dot)com> wrote:

> *custom_guc_flags-0828.patch
> My only other concern is the changes to DefineCustom*() to tag the new
> flags param. Now I think anyone who uses Custom gucs will want/should
> be able to set that. I did not see any people in contrib using it but
> did not look on PGfoundry. Do we need to document the change
> somewhere for people who might be using it???

Now it is done with DefineCustomVariable(type, variable) and keep
existing functions as-is for backward compatibility.

Some people will be happy if the functions are documented,
but we need to define 'stable-internal-functions' between
SPI (stable expoted functions) and unstable internal functions.

> *psql_ignore_notices-0828.patch:
> I think this should get dropped.

Hmm, I agree that hiding all messages is not good. I removed it.
If some people need it, we can reconsider it in a separated discussion.

> *auto_explalin.c:
> init_instrument()
> The only "cleaner" way I can
> see is to add a hook for CreateQueryDesc so we can overload
> doInstrument and ExecInitNode will InstrAlloc them all for us.

I wanted to avoid modifying core codes as far as possible,
but I see it was ugly. Now I added 'force_instrument' global
variable as a hook for CreateQueryDesc.

> the only other comment I have is suset_assign() do we really need to
> be a superuser if its all going to LOG ? There was some concern about
> explaining security definer functions right? but surely a regular
> explain on those shows the same thing as this explain? Or what am I
> missing?

Almost logging options in postgres are only for superusers. So I think
auto_explain options should not be modified by non-superusers, too.

If you want to permit usage for users, you can create a security definer
wrapper function to allow it, no?

CREATE FUNCTION set_explain_log_min_duration(text) RETURNS text AS
$$ SELECT set_config('explain.log_min_duration', $1, false); $$
LANGUAGE sql SECURITY DEFINER;

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

On Thu, Oct 9, 2008 at 03:06, ITAGAKI Takahiro
<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> Thanks for your reviewing, Alex.
> I applied your comments to my patch.

Sorry for the late reply! Somehow I missed this, saw it on the commit
fest wiki :)

>> *custom_guc_flags-0828.patch
>> My only other concern is the changes to DefineCustom*() to tag the new
>> flags param. Now I think anyone who uses Custom gucs will want/should
>> be able to set that. I did not see any people in contrib using it but
>> did not look on PGfoundry. Do we need to document the change
>> somewhere for people who might be using it???
>
> Now it is done with DefineCustomVariable(type, variable) and keep
> existing functions as-is for backward compatibility.

Ok that seems better...

> Some people will be happy if the functions are documented,
> but we need to define 'stable-internal-functions' between
> SPI (stable expoted functions) and unstable internal functions.

Right, thats why I was asking :)

>> *auto_explalin.c:
>> init_instrument()
>> The only "cleaner" way I can
>> see is to add a hook for CreateQueryDesc so we can overload
>> doInstrument and ExecInitNode will InstrAlloc them all for us.
>
> I wanted to avoid modifying core codes as far as possible,
> but I see it was ugly. Now I added 'force_instrument' global
> variable as a hook for CreateQueryDesc.

Yeah, well if we are not to worried about it getting out of sync when
people add new node/scan types what you had before was probably ok. I
was just trying to stimulate my own and maybe others brains who are on
the list that might have better ideas. But at least now the commiter
has 2 options here :)

>> the only other comment I have is suset_assign() do we really need to
>> be a superuser if its all going to LOG ? There was some concern about
>> explaining security definer functions right? but surely a regular
>> explain on those shows the same thing as this explain? Or what am I
>> missing?
>
> Almost logging options in postgres are only for superusers. So I think
> auto_explain options should not be modified by non-superusers, too.

Ok thanks that makes sense.

On Thu, 2008-10-09 at 19:06 +0900, ITAGAKI Takahiro wrote:
> Thanks for your reviewing, Alex.
> I applied your comments to my patch.

Hi,

This seems like a very useful feature, and it works nicely.

Initial comments:

1. Please sync with HEAD. There was a change made on Oct. 31st that
affects this patch, and prevents it from building properly.

2. Add it to the list of contrib modules to build in contrib/Makefile

Regards,
Jeff Davis

On Thu, 2008-10-09 at 19:06 +0900, ITAGAKI Takahiro wrote:
> Thanks for your reviewing, Alex.
> I applied your comments to my patch.
>

I made a few changes:

1. fixed some minor issues with auto_explain.sgml so that it would build
(and renamed to auto-explain.sgml to match other files)

2. added link in contrib.sgml

3. added line to contrib/Makefile to build the module

4. bundled it all up as one patch to make it easier to move around

It still needs to be merged with HEAD.

Regards,
Jeff Davis

Jeff Davis wrote:
> It still needs to be merged with HEAD.
>
ExecutorRun function signature has changed to return void. Other than that
it seems OK. I'll add a few additional notes:

One thing that I noticed was that tab completion queries are also explained
if "explain.log_min_duration" is set to zero. Actually this also applies to
psql \dX commands. Don't know if this is deliberate or not. Example:

load 'auto_explain';
set explain.log_min_duration = 0;
set client_min_messages = LOG;
select * from pg_catalog.^ILOG: duration: 4.713 ms plan:
Limit (cost=27.41..27.44 rows=3 width=85) (actual time=4.023..4.418 rows=75 loops=1)
...

I have a feeling that this can become somewhat annoying during an interactive
troubleshooting session.

Another thing is a feature I am interested in -- ability to auto-explain statements
execututed from within functions. I'm thinking of adding an extra boolean GUC --
"explain.log_nested_statements" (defaults to false). Quick test seems to give
expected results, but there maybe something I missed.

regards,
Martin

On Fri, 2008-11-07 at 18:03 +0200, Martin Pihlak wrote:
> One thing that I noticed was that tab completion queries are also explained
> if "explain.log_min_duration" is set to zero. Actually this also applies to
> psql \dX commands. Don't know if this is deliberate or not. Example:

It's logged at the LOG level, just like log_min_duration_statement, and
seems to have the same behavior. What do you think it should do
differently?

> Another thing is a feature I am interested in -- ability to auto-explain statements
> execututed from within functions. I'm thinking of adding an extra boolean GUC --
> "explain.log_nested_statements" (defaults to false). Quick test seems to give
> expected results, but there maybe something I missed.
>

I like that idea, I'll take a look at it.

Regards,
Jeff Davis

Jeff Davis wrote:
> It's logged at the LOG level, just like log_min_duration_statement, and
> seems to have the same behavior. What do you think it should do
> differently?
>
There was actually a patch to disable the psql notices, but there were
some concerns and I think it was removed:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01264.php
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01752.php

Patch is at:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01274.php
and seems to get rid of the annoying messages. If there aren't any
major issues with it, I think it should be re-added.

regards,
Martin

On Fri, 2008-11-07 at 22:23 +0200, Martin Pihlak wrote:
> Patch is at:
> http://archives.postgresql.org/pgsql-hackers/2008-08/msg01274.php
> and seems to get rid of the annoying messages. If there aren't any
> major issues with it, I think it should be re-added.
>

I still don't understand why this psql patch is desirable. Who sets
their client_min_messages to LOG in psql? And if they do, why would they
expect different behavior that they always got from the already-existing
GUC log_min_duration_statement?

Regards,
Jeff Davis

Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> writes:
> There was actually a patch to disable the psql notices, but there were
> some concerns and I think it was removed:
> http://archives.postgresql.org/pgsql-hackers/2008-07/msg01264.php
> http://archives.postgresql.org/pgsql-hackers/2008-09/msg01752.php

> Patch is at:
> http://archives.postgresql.org/pgsql-hackers/2008-08/msg01274.php
> and seems to get rid of the annoying messages. If there aren't any
> major issues with it, I think it should be re-added.

As I said in the first-quoted message, that patch was simply a band-aid
trying to cover poorly designed behavior; and it still is. The fact is
that most clients will not react very gracefully to unexpected notice
messages, especially not large numbers of same.

regards, tom lane

Jeff Davis wrote:
> I still don't understand why this psql patch is desirable. Who sets
> their client_min_messages to LOG in psql? And if they do, why would they
> expect different behavior that they always got from the already-existing
> GUC log_min_duration_statement?
>
I know a few ;) In my environment the auto-explain is especially useful when
used from within psql. Server logs are not always easy to get to, and it is
difficult to extract the interesting bits (large files and lots of log traffic).

For me the primary use of auto-explain would be interactive troubleshooting.
The troublesome statements usually involve several nested function calls and
are tedious to trace manually. With auto-explain I fire up psql, load the
module, set the client log level, run the statements and immediately see
what's going on. I bet that lot of the developers and QA folk would use it
similarly.

You are of course right about the log_min_duration_statement, also the
log_executor_stats etc. behave similarly. So indeed, the "ignore notices" patch
is not necessarily part of auto-explain.

Regards,
Martin

On Sat, 2008-11-08 at 12:18 +0200, Martin Pihlak wrote:
> For me the primary use of auto-explain would be interactive troubleshooting.
> The troublesome statements usually involve several nested function calls and
> are tedious to trace manually. With auto-explain I fire up psql, load the
> module, set the client log level, run the statements and immediately see
> what's going on. I bet that lot of the developers and QA folk would use it
> similarly.
>

I think the cost in terms of inconsistency here is just too high for the
benefit. If you set the client_min_messages to LOG, you should really
get *all* the log messages, not all except for those that happen to
occur when psql is in some implicit mode that's invisible to the user.

By the way, a possible solution for the problem you describe is to
simply set explain.log_min_duration=1s or something, so that you won't
see tab completion queries (or, if you do, this is the least of your
problems). Or, just disable tab completion.

> You are of course right about the log_min_duration_statement, also the
> log_executor_stats etc. behave similarly. So indeed, the "ignore notices" patch
> is not necessarily part of auto-explain.
>

I agree that there might be room for improvement in psql's handling of
notices, and that the logging system might be made more flexible. But
let's just keep it simple so that we get something in 8.4. I think
auto-explain will be very useful to a lot of people as-is.

Regards,
Jeff Davis

On Fri, 2008-11-07 at 18:03 +0200, Martin Pihlak wrote:
> Another thing is a feature I am interested in -- ability to auto-explain statements
> execututed from within functions. I'm thinking of adding an extra boolean GUC --
> "explain.log_nested_statements" (defaults to false). Quick test seems to give
> expected results, but there maybe something I missed.

Thanks.

I applied this patch for log_nested_statements and I merged with HEAD.
Current patch attached.

One thing I'm unsure of (this question is for ITAGAKI Takahiro): why is
it necessary to define a new function DefineCustomVariable(), when there
are already functions DefineCustomBoolVariable() and
DefineCustomIntVariable()?

Regards,
Jeff Davis

On Sat, 2008-11-08 at 11:32 -0800, Jeff Davis wrote:
> One thing I'm unsure of (this question is for ITAGAKI Takahiro): why is
> it necessary to define a new function DefineCustomVariable(), when there
> are already functions DefineCustomBoolVariable() and
> DefineCustomIntVariable()?
>

Oh, I see. It's needed to set the flags to GUC_UNIT_MS.

Another question: what is explain.log_analyze supposed to do? Changing
it doesn't seem to have an effect; it always prints out the actual time.

Regards,
Jeff Davis

Thank you for reviewing.

Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Another question: what is explain.log_analyze supposed to do? Changing
> it doesn't seem to have an effect; it always prints out the actual time.

That's because explain.log_analyze requires executor instruments,
and it's not free. I think we'd better to have an option to avoid
the overheads... Oops, I found my bug when force_instrument is
turned on. It should be enabled only when
(explain_log_min_duration >= 0 && explain_log_analyze).

I send a new patch to fix it. A documentation about
explain.log_nested_statements is also added to the sgml file.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

On Mon, 2008-11-10 at 18:02 +0900, ITAGAKI Takahiro wrote:
> That's because explain.log_analyze requires executor instruments,
> and it's not free. I think we'd better to have an option to avoid
> the overheads... Oops, I found my bug when force_instrument is
> turned on. It should be enabled only when
> (explain_log_min_duration >= 0 && explain_log_analyze).
>
> I send a new patch to fix it. A documentation about
> explain.log_nested_statements is also added to the sgml file.
>

Great. I attached a patch with some minor documentation changes.

There seems to be no auto_explain view, so I assumed that section of the
docs was old, and I removed it. Let me know if you intend to include the
view.

Thanks! This patch is ready to go, as far as I'm concerned.

Regards,
Jeff Davis

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Thanks! This patch is ready to go, as far as I'm concerned.

This patch seems to contain a subset of the "contrib infrastructure"
patch that's listed separately on the commitfest page. While I have
no strong objection to what's here, I'm wondering what sort of process
we want to follow. Is the infrastructure stuff getting separately
reviewed or not?

regards, tom lane

On Thu, 2008-11-13 at 14:31 -0500, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > Thanks! This patch is ready to go, as far as I'm concerned.
>
> This patch seems to contain a subset of the "contrib infrastructure"
> patch that's listed separately on the commitfest page. While I have
> no strong objection to what's here, I'm wondering what sort of process
> we want to follow. Is the infrastructure stuff getting separately
> reviewed or not?
>

I can review it, but not until this weekend. It looks like someone
already added me to the list of reviewers on that patch. I'm not sure if
Matthew Wetmore has already started reviewing it or not.

Regards,
Jeff Davis

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Thu, 2008-11-13 at 14:31 -0500, Tom Lane wrote:
>> This patch seems to contain a subset of the "contrib infrastructure"
>> patch that's listed separately on the commitfest page. While I have
>> no strong objection to what's here, I'm wondering what sort of process
>> we want to follow. Is the infrastructure stuff getting separately
>> reviewed or not?

> I can review it, but not until this weekend. It looks like someone
> already added me to the list of reviewers on that patch. I'm not sure if
> Matthew Wetmore has already started reviewing it or not.

Now that I look closer, the "contrib infrastructure" item is just a
combination of the auto_explain and pg_stat_statements items, and I
guess the reason you and Matthew were shown as reviewers was that
you'd each been assigned one of those two items. As far as I can see
this is just confusing and duplicative. I've removed the
"infrastructure" item from the commitfest page; I think we can
proceed with the two other items separately. If there's any conflict
in the two patches we can resolve it after the first one gets applied.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Now that I look closer, the "contrib infrastructure" item is just a
> combination of the auto_explain and pg_stat_statements items, and I
> guess the reason you and Matthew were shown as reviewers was that
> you'd each been assigned one of those two items. As far as I can see
> this is just confusing and duplicative.

That's right. Sorry for your confusing.

> I think we can
> proceed with the two other items separately. If there's any conflict
> in the two patches we can resolve it after the first one gets applied.

contrib/auto_explain patch is "Ready for committer" even without
the QueryDesc patch. So please apply it if there are no problems.
I'll rewrite contrib/pg_stat_statements to use the new feature
in the QueryDesc patch and avoid confliction from the first one.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Mon, 2008-11-10 at 18:02 +0900, ITAGAKI Takahiro wrote:
>> That's because explain.log_analyze requires executor instruments,
>> and it's not free. I think we'd better to have an option to avoid
>> the overheads... Oops, I found my bug when force_instrument is
>> turned on. It should be enabled only when
>> (explain_log_min_duration >= 0 && explain_log_analyze).
>>
>> I send a new patch to fix it. A documentation about
>> explain.log_nested_statements is also added to the sgml file.

> Great. I attached a patch with some minor documentation changes.

Looking at this patch now ...

I don't like the force_instrument thing too much at all. It's brute
force and it doesn't get every case right today, much less in the future
--- for instance, it uselessly forces instrumentation on an EXPLAIN
startup, because it can't react to EXEC_FLAG_EXPLAIN_ONLY.

I think a cleaner solution here is to create a hook for ExecutorStart
just as we have done for ExecutorRun --- and probably there ought to
be one for ExecutorEnd for completeness. auto_explain would then
hook into ExecutorStart and force doInstrument true on appropriate
conditions.

Another issue that is bothering me is that it's not clear that an
ExecutorRun execution is the right unit for measuring the runtime of a
query --- this would be quite misleading for queries that are executed a
bit at a time, such as SQL functions and cursor queries. I think it'd
be better to accumulate runtime and then report in an ExecutorEnd hook.
This would likely require adding a struct Instrumentation * field to
QueryDesc in which to track the total ExecutorRun timing, but I don't
see anything very wrong with that. The core system would just leave it
NULL, and the ExecutorStart hook could fill it in when it wants the
query to be tracked by the other two hooks.

regards, tom lane

Ok, I'm looking at the direction of ExecutorStart/End hooks...

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> This would likely require adding a struct Instrumentation * field to
> QueryDesc in which to track the total ExecutorRun timing

I think instr_time is enough here,
but why do you think Instrumentation is needed?

There might be another approach to have a stopwatch stack in
the contrib module instead of the core. I think it is cleaner
because it works even if multiple modules use the stopwatch
at the same time. Am I missing something?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

I wrote:

> There might be another approach to have a stopwatch stack in
> the contrib module instead of the core. I think it is cleaner
> because it works even if multiple modules use the stopwatch
> at the same time. Am I missing something?

Ooops, it should be:
... because each multiple module can use its own stopwatch
stack at the same time.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This would likely require adding a struct Instrumentation * field to
>> QueryDesc in which to track the total ExecutorRun timing

> I think instr_time is enough here,
> but why do you think Instrumentation is needed?

Well, it's more general. You could think of ExecutorRun as being like a
plan node, in which case all the fields of struct Instrumentation are
potentially useful. If a contrib module doesn't want to use them,
of course it doesn't have to.

Or I guess we could just put a void * there and not try to wire down
its usage.

> There might be another approach to have a stopwatch stack in
> the contrib module instead of the core. I think it is cleaner
> because it works even if multiple modules use the stopwatch
> at the same time. Am I missing something?

I think this will be mighty messy ...

regards, tom lane

Here is an update version of contrib/auto_explain patch.

Now it uses new ExecutorStart_hook and ExecutorEnd_hook.
When we execute queries using cursor, FETCHes are accumulated
and reported only once on CLOSE.

A new argument 'flags' is added in DefineCustomXXXVariable()
and custom GUC variables are defined with it. Some GUC_* constants
are moved to guc.h from guc_tables.h.

A variable "Instrumentation *totaltime" is added in QueryDesc.
It is not used by the core in default (always NULL), but initialized
by contrib modules. However, the core update the counter if it is
not NULL because multiple contrib modules might use it.
If the core don't update the counter, only one of the modules
should update it, but it's hard to determine which one should do.

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> >> This would likely require adding a struct Instrumentation * field to
> Well, it's more general. You could think of ExecutorRun as being like a
> plan node, in which case all the fields of struct Instrumentation are
> potentially useful. If a contrib module doesn't want to use them,
> of course it doesn't have to.

Instrumentation is enough for auto_explain, so I used it for now.
However, pg_stat_statements also use the field and requires other
counters (buffer usages and rusage). It might replace the field
with another struct. Then we might need to reconsider how to deal
with session statistics, suggested by Vladimir.

"Vladimir Sitnikov" <sitnikov(dot)vladimir(at)gmail(dot)com> wrote:
> I wish PostgreSQL had some kind of pg_session_statistics view that reports
> resource usage statistics for each session.
> For instance, it could expose "buffer usage" to the client, so it could get
> more details on resource usage. For instance, I would like to see a new tab
> in pgAdmin that shows "total number of buffer gets", "number of WAL records
> created", "number of rows sorted" and similar information after query
> finishes (even in plain "execute" mode).

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Here is an update version of contrib/auto_explain patch.

Applied with some editorialization, mostly around the GUC stuff.

regards, tom lane