Re: contrib/pg_stat_statements 1202

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

> #define GUCNAME(name) ("statistics." name)
>
> Why statistics?
> Would not something like stat_statements make more sense? Statistics
> seems fairly arbitrary...

Not to use duplicated "statements" words;
variable names contains "statements" already.
- stat_statements.max_statements
- stat_statements.track_statements
seem to be ugly for me, but avoiding arbitrariness might be more
important. If there are agreements, I will to change the prefix.

> Also per the
> /* XXX: Should USAGE_EXEC reflect execution time and/or buffer usage? */
>
> Maybe it should be configurable, personally I would want something
> like # of calls / time. Mainly because I don't for instance really
> care that my backups get tracked but would be more interested in the
> things that get called most often that also take the longest. (aka
> the most bang for the buck, as far as optimizing those goes...)

Configurability is better, but we need documentations of how to
configure them and I have no clear idea for it. Also, we already have
means for logging slow queries. We could use the logging for slow
queries executed rarely and use the module queries executed many times.

Excluding backup scripts is easy; You can create a database role for
backup and disable statement-tracking for the user using ALTER ROLE.

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