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