On 25/10/2023 20:00, Andrei Zubkov wrote:
Hi Andrei,
On Wed, 2023-10-25 at 13:59 +0700, Andrei Lepikhov wrote:
But minmax_stats_since and changes in the UI of the reset routine
look like syntactic sugar here.
I can't convince myself that it is really needed. Do you have some
set of cases that can enforce the changes proposed?
Yes, it looks strange, but it is needed in some way.
The main purpose of this patch is to provide means for sampling
solutions for collecting statistics data in series of samples. The
first goal here - is to be sure that the statement was not evicted and
come back between samples (especially between rare samples). This is
the target of the stats_since field. The second goal - is the ability
of getting all statistic increments for the interval between samples.
All statistics provided by pg_stat_statements with except of min/max
values can be calculated for the interval since the last sample knowing
the values in the last and current samples. We need a way to get
min/max values too. This is achieved by min/max reset performed by the
sampling solution. The minmax_stats_since field is here for the same
purpose - the sampling solution is need to be sure that no one have
done a min/max reset between samples. And if such reset was performed
at least we know when it was performed.
It is the gist of my question. If needed, You can remove the record by
(userid, dbOid, queryId). As I understand, this extension is usually
used by an administrator. Who can reset these parameters except you and
the DBMS?
--
regards,
Andrei Lepikhov
Postgres Professional
