From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Tomas Vondra <tv(at)fuzzy(dot)cz> |
Subject: | Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset |
Date: | 2022-03-29 23:43:28 |
Message-ID: | 20220329234328.kvklxhnsewvivaxd@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-03-29 23:48:21 | Re: Add parameter jit_warn_above_fraction |
Previous Message | David Rowley | 2022-03-29 23:41:41 | Re: Add parameter jit_warn_above_fraction |