From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Andrei Zubkov <zubkov(at)moonset(dot)ru> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Andres Freund <andres(at)anarazel(dot)de>, "Anton A(dot) Melnikov" <aamelnikov(at)inbox(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements |
Date: | 2022-04-03 07:07:25 |
Message-ID: | 20220403070725.efgxe7i74m6cbg4h@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <varname>pg_stat_statements.track_planning</varname> is enabled,
- otherwise zero)
+ otherwise zero), this field will contain zero until this statement
+ is planned fist time after reset performed by the
+ <function>pg_stat_statements_reset</function> function with the
+ <structfield>minmax_only</structfield> parameter set to <literal>true</literal>
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 <varname>pg_stat_statements.track_planning</varname>
is disabled, or if the counter has been reset using the the
<function>pg_stat_statements_reset</function> function with the
<structfield>minmax_only</structfield> parameter set to <literal>true</literal>
and never been planned since.
<primary>pg_stat_statements_reset</primary>
</indexterm>
@@ -589,6 +623,20 @@
If all statistics in the <filename>pg_stat_statements</filename>
view are discarded, it will also reset the statistics in the
<structname>pg_stat_statements_info</structname> view.
+ When <structfield>minmax_only</structfield> is <literal>true</literal> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-04-03 07:09:07 | Re: Fix overflow in DecodeInterval |
Previous Message | Tatsuo Ishii | 2022-04-03 06:28:19 | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |