Hi,
On 2022-03-29 14:14:05 -0700, David G. Johnston wrote:
> On Tue, Mar 29, 2022 at 1:37 PM Andres Freund <andres@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
