Hi,
On 2022-03-23 18:47:58 -0700, David G. Johnston wrote:
> It also seems that each tracked object type needs to have its own
> last_reset field (we could choose to name it stats_reset too, leaving
> pg_stat_database.last_reset as the only anomaly) added as an implied
> behavior needed for such individualized resetting. I would go with
> *.last_reset though and leave the absence of pg_stat_archiver.last_reset as
> the anomaly (or just add it redundantly for consistency).
It's not free to track more information. We always have the stats for the
whole system in memory at least once (stats collector currently, shared hash
table with shared memory stats patch), often more than that (stats accessing
backends).
> I don't see removing existing functionality as a good course to getting a
> consistent implementation; we should just push forward with figuring out
> what is missing and fill in those gaps. At worst if that isn't something
> we want to fix right now our new setup should at least leave the status quo
> behaviors in place.
Well, it depends on whether there's an actual use case for those super fine
grained reset functions. Neither docs nor the thread introducing them
presented that. We don't have SQL level stats
values either.
Greetings,
Andres Freund
