Re: Add new option 'all' to pg_stat_reset_shared()

From: Andres Freund <andres(at)anarazel(dot)de>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: bharath(dot)rupireddyforpostgres(at)gmail(dot)com, torikoshia(at)oss(dot)nttdata(dot)com, boekewurm+postgres(at)gmail(dot)com, michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add new option 'all' to pg_stat_reset_shared()
Date: 2023-11-08 04:18:30
Message-ID: 20231108041830.5ffp5v3dellbeibt@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-11-08 10:08:42 +0900, Kyotaro Horiguchi wrote:
> At Mon, 6 Nov 2023 14:00:13 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> > On Mon, Nov 6, 2023 at 11:39 AM torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> wrote:
> > > Since each stats, except wal_prefetch was reset acquiring LWLock,
> > > attached PoC patch makes the call atomic by using these LWlocks.
> > >
> > > If this is the right direction, I'll try to make wal_prefetch also take
> > > LWLock.
>
> I must say, I have reservations about this approach. The main concern
> is the duplication of reset code, which has been efficiently
> encapsulated for individual targets, into this location. This practice
> degrades the maintainability and clarity of the code.

Yes, as-is this seems to evolve the code in precisely the wrong direction. We
want less central awareness of different types of stats, not more. The
proposed new code is far longer than the current pg_stat_reset(), despite
doing something conceptually simpler.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-11-08 04:24:45 Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Previous Message Andres Freund 2023-11-08 04:13:31 Re: Add new option 'all' to pg_stat_reset_shared()