Hi, On 2022-03-30 14:08:41 -0700, Andres Freund wrote: > On 2022-03-30 14:42:23 -0400, Robert Haas wrote: > > On Tue, Mar 29, 2022 at 5:01 PM Andres Freund <and...@anarazel.de> wrote: > > > I can think of these different times: > > > > > > - Last time stats were removed due to starting up in crash recovery > > > - Last time stats were created from scratch, because no stats data file > > > was > > > present at startup > > > - Last time stats were thrown away due to corruption > > > - Last time a subset of stats were reset using one of the pg_reset* > > > functions > > > > > > Makes sense? > > > > Yes. Possibly that last could be broken in to two: when all stats were > > last reset, when some stats were last reset. > > Believe it or not, we don't currently have a function to reset all stats. We > should definitely add that though, because the invocation to reset all stats > gets more ridiculous^Wcomplicated with each release.
I assume we'd want all of these to be persistent (until the next time stats are lost, of course)? We currently have the following SQL functions showing reset times: pg_stat_get_bgwriter_stat_reset_time pg_stat_get_db_stat_reset_time and kind of related: pg_stat_get_snapshot_timestamp There's also a few functions showing the last time something has happened, like pg_stat_get_last_analyze_time(). Trying to fit those patterns we could add functions like: pg_stat_get_stats_last_cleared_recovery_time pg_stat_get_stats_last_cleared_corrupted_time pg_stat_get_stats_last_not_present_time pg_stat_get_stats_last_partially_reset_time Not great, but I don't immediately have a better idea. Maybe it'd look better as a view / SRF? pg_stat_stats / pg_stat_get_stats()? Potential column names: - cleared_recovery_time - cleared_corrupted_time - not_preset_time - partially_reset_time It's not a lot of time to code these up. However, it's late in cycle, and they're not suddenly needed due to shared memory stats, so I have a few doubts about adding them now? Greetings, Andres Freund
