Hi, On 2022-03-29 14:14:05 -0700, David G. Johnston wrote: > On Tue, Mar 29, 2022 at 1:37 PM Andres Freund <and...@anarazel.de> wrote: > > > > 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. > > > > > That seems like only half a solution. The reasoning for doing such a split > for pg_stat_database is identical to the reason that new fields should be > added to pg_stat_all_tables and pg_stat_user_functions (and possibly > others).
Not really IMO. There's obviously the space usage aspect - there's always fewer pg_stat_database stats than relation stats. But more importantly, a per-relation/function reset field wouldn't address Tomas's concern: He wants a single thing to check to see if any stats have been reset - and that's imo a quite reasonable desire. > pg_stat_all_tables already has 16 bigint fields, 4 timestamptz fields, 2 > names and an oid. Seems like one more timestamptz field is a marginal > increase whose presence lets us keep the already implemented per-table > reset mechanism. We should at least measure the impact that adding the > field has before deciding its presence is too costly. Because of the desire for a single place to check whether there has been a reset within a database, that's imo an orthogonal debate. Greetings, Andres Freund