From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add new option 'all' to pg_stat_reset_shared() |
Date: | 2023-11-02 19:25:00 |
Message-ID: | CALj2ACXQTKMYL-aYKM=XObQ27wyD3V2yRGeF1z=jJN7vptgNgg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 1, 2023 at 4:24 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Oct 31, 2023 at 04:26:18PM +0900, torikoshia wrote:
> > Yes, calling pg_stat_reset_shared() for all stats types can do what I wanted
> > to do.
> > But calling it with 6 different parameters seems tiresome and I thought it
> > would be convenient to have a parameter to delete all cluster-wide
> > statistics at once.
> >
> > I may be wrong, but I imagine that it's more common to want to delete all of
> > the statistics for an entire cluster rather than just a portion of it.
>
> If more flexibility is wanted in this function, could it be an option
> to consider a flavor like pg_stat_reset_shared(text[]), where it is
> possible to specify a list of shared stats types to reset? Perhaps
> there are no real use cases for it, just wanted to mention it anyway
> regarding the fact that it could have benefits to refactor this code
> to use a bitwise operator for its internals with bit flags for each
> type.
I don't see a strong reason to introduce yet-another API when someone
can just call things in a loop. I could recollect a recent analogy - a
proposal to have a way to define multiple custom wait events with a
single function call instead of callers defining in a loop didn't draw
much interest.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2023-11-02 19:32:27 | Re: Detoasting optionally to make Explain-Analyze less misleading |
Previous Message | stepan rutz | 2023-11-02 19:09:30 | Re: Detoasting optionally to make Explain-Analyze less misleading |