Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

Поиск
Список
Период
Сортировка
Искать
От
Julien Rouhaud
Тема
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Дата
Msg-id
20220403070725.efgxe7i74m6cbg4h@jrouhaud
Ответ на
Список
Дерево обсуждения
[PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Julien Rouhaud <rjuju123@gmail.com>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Seino Yuki <seinoyu@oss.nttdata.com>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Julien Rouhaud <rjuju123@gmail.com>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Chengxi Sun <sunchengxi@highgo.com>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
Re[2]: [PATCH] Tracking statements entry timestamp in pg_stat_statements Мельников Антон Андреевич <aamelnikov@inbox.ru>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements Andrei Zubkov <zubkov@moonset.ru>
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements "Anton A. Melnikov" <aamelnikov@inbox.ru>
On Sun, Apr 03, 2022 at 07:32:47AM +0300, Andrei Zubkov wrote:
> v11 attached

+       /* When requested reset only min/max statistics of an entry */ \
+       entry_counters = &entry->counters; \
+       for (int kind = 0; kind < PGSS_NUMKIND; kind++) \
+       { \
+           entry_counters->max_time[kind] = 0; \
+           entry_counters->min_time[kind] = 0; \
+       } \
[...]
+static TimestampTz
+entry_reset(Oid userid, Oid dbid, uint64 queryid, bool minmax_only)
 {
    HASH_SEQ_STATUS hash_seq;
    pgssEntry  *entry;
+   Counters   *entry_counters;

Do we really need an extra variable?  Why not simply using
entry->counters.xxx_time[kind]?

Also, I think it's better to make the macro more like function looking, so
SINGLE_ENTRY_RESET().

index f2e822acd3..c2af29866b 100644
--- a/contrib/pg_stat_statements/sql/oldextversions.sql
+++ b/contrib/pg_stat_statements/sql/oldextversions.sql
@@ -36,4 +36,12 @@ AlTER EXTENSION pg_stat_statements UPDATE TO '1.8';
 \d pg_stat_statements
 SELECT pg_get_functiondef('pg_stat_statements_reset'::regproc);

+ALTER EXTENSION pg_stat_statements UPDATE TO '1.9';
+\d pg_stat_statements
+\d pg_stat_statements_info
+SELECT pg_get_functiondef('pg_stat_statements_reset'::regproc);

I don't think this bring any useful coverage.

        Minimum time spent planning the statement, in milliseconds
        (if pg_stat_statements.track_planning is enabled,
-       otherwise zero)
+       otherwise zero), this field will contain zero until this statement
+       is planned fist time after reset performed by the
+       pg_stat_statements_reset function with the
+       minmax_only parameter set to true

I think this need some rewording (and s/fist/first).  Maybe:

Minimum time spent planning the statement, in milliseconds.

This field will be zero if pg_stat_statements.track_planning
is disabled, or if the counter has been reset using the the
pg_stat_statements_reset function with the
minmax_only parameter set to true
and never been planned since.

       pg_stat_statements_reset
      
@@ -589,6 +623,20 @@
       If all statistics in the pg_stat_statements
       view are discarded, it will also reset the statistics in the
       pg_stat_statements_info view.
+      When minmax_only is true only the
+      values of minimun and maximum execution and planning time will be reset (i.e.

Nitpicking: I would say planning and execution time, as the fields are in this
order in the view/function.


В списке pgsql-hackers по дате отправления
От: Tatsuo Ishii
Дата:
От: Tom Lane
Дата:
FAQ