Hi,
On 2022-03-24 13:12:24 +0100, Tomas Vondra wrote:
> 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.
It's not that you'd use it as the sole means of determining the time
delta. But using it to see if stats were reset between two samples of
pg_stat_database imo makes plenty sense.
> 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).
I wonder if we should just split that per-database timestamp into two. One
about the pg_stat_database contents, one about per-database stats? That
doesn't have the same memory-usage-increase concerns as adding
per-table/function reset stats.
Greetings,
Andres Freund
