Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

From: "Anton A(dot) Melnikov" <aamelnikov(at)inbox(dot)ru>
To: Andrei Zubkov <zubkov(at)moonset(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date: 2021-12-22 01:25:33
Message-ID: ecccd6df-7c96-bbc3-8ccf-eb96234f8120@inbox.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-12-22 01:25:54 Re: CREATEROLE and role ownership hierarchies
Previous Message houzj.fnst@fujitsu.com 2021-12-22 01:14:26 RE: parallel vacuum comments