Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Tomas Vondra <tv(at)fuzzy(dot)cz>
Subject: Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Date: 2022-03-24 12:12:24
Message-ID: 4935d210-d5fb-efad-c2f8-893c2b06f8b8@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/24/22 01:59, Andres Freund wrote:
> Hi,
>
> On 2022-03-23 17:55:16 -0700, Andres Freund wrote:
>> Maybe I just don't understand what these reset functions are intended for?
>> Their introduction [3] didn't explain much either. To me the behaviour of
>> resetting pg_stat_database.stats_reset but nothing else in pg_stat_database
>> makes them kind of dangerous.
>
> Forgot to add: At the very least we should document that weird behaviour,
> because it's certainly not obvious. But imo we should either remove the
> behaviour or drop the functions.
>

I agree it should have been documented, but I still stand behind the
current behavior. I'm not willing to die on this hill, but I think the
reasoning was/is sound.

Firstly, calculating transactions/second, reads/second just from by
looking at pg_stat_database data (counter and stat_reset) is nonsense.
It might work for short time periods, but for anything longer it's bound
to give you bogus results - you don't even know if the system was
running at all, and so on.

Secondly, to do anything really meaningful you need to calculate deltas,
and be able to detect if some of the stats were reset for the particular
interval. And the stat_reset timestamp was designed to be a simple way
to detect that (instead of having to inspect all individual timestamps).

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2022-03-24 12:12:56 Re: Documenting when to retry on serialization failure
Previous Message Michael Paquier 2022-03-24 12:10:29 Re: Estimating HugePages Requirements?