On Wed, Mar 30, 2022 at 1:39 PM Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2022-03-30 12:29:51 -0700, David G. Johnston wrote: > > On Wednesday, March 30, 2022, Andres Freund <and...@anarazel.de> wrote: > > > My current proposal is to just have two reset times. One for the > contents > > > of > > > pg_stat_database (i.e. not affected by > pg_stat_reset_single_*_counters()), > > > and > > > one for stats within the entire database. > > > What IS it affected by? And does whatever affects it affect anything > else? > > pg_stat_reset() resets the current database's stats. That includes the > database's row in pg_stat_database and all table and function stats. > > Right, so basically it updates both of the fields you are talking about. The existing stats_reset field is also updated upon calling pg_stat_reset_single_*_counters() So when the two fields are different we know that at least one relation or function statistic row is out-of-sync with the rest of the database, we just don't know which one(s). This is an improvement over the status quo where the single timestamp cannot be trusted to mean anything useful. The DBA can execute pg_stat_reset() to get the statistics back into a common state. As an added bonus we will always have a reference timestamp for when the pg_stat_database database record was last reset (as well as any other statistic record that can only be reset by using pg_stat_reset). David J.
