On 03.12.2021 19:55, Andrei Zubkov wrote:
On Fri, 2021-12-03 at 17:03 +0300, Andrei Zubkov wrote:
...
What if we'll create a new view for such resettable fields? It will
make description of views and reset functions in the docs much more
clear.
Hi, Andrey!
I completely agree that creating a separate view for these new fields is
the most correct thing to do.
As for variable names, the term global is already used for global
statistics, in particular in the struct pgssGlobalStats.
The considered timestamps refer to per statement level
as pointed out in the struct pgssEntry's comment. Therefore, i think
it's better to rename gstats_since to just stats_reset in the same way.
Also it might be better to use the term 'auxiliary' and use the same
approach as for existent similar vars.
So internally it might look something like this:
double aux_min_time[PGSS_NUMKIND];
double aux_max_time[PGSS_NUMKIND];
TimestampTz aux_stats_reset;
And at the view level:
aux_min_plan_time float8,
aux_max_plan_time float8,
aux_min_exec_time float8,
aux_max_exec_time float8,
aux_stats_reset timestamp with time zone
Functions names might be pg_stat_statements_aux() and
pg_stat_statements_aux_reset().
The top-level application may find out period the aux extrema were
collected by determining which reset was closer as follows:
data_collect_period = aux_stats_reset > stats_reset ?
now - aux_stats_reset : now - stats_reset;
and decide not to trust this data if the period was too small.
For correct work aux_stats_reset must be updated and aux extrema values
must be reset simultaneously with updating of stats_reset therefore some
synchronization needed to avoid race with possible external reset.
I've tested the patch v4 and didn't find any evident problems.
Contrib installcheck said:
test pg_stat_statements ... ok 163 ms
test oldextversions ... ok 46 ms
With best regards,
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
