Hi, On 2023-11-03 00:55:00 +0530, Bharath Rupireddy wrote: > On Wed, Nov 1, 2023 at 4:24 AM Michael Paquier <mich...@paquier.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.
Yes, agreed. However, I'd suggest adding pg_stat_reset_shared(), instead of pg_stat_reset_shared('all') for this purpose. > > 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 think there is much point in such an API - if the caller actually wants to delete individual stats, it's not too hard to loop. But most of the time resetting individual stats doesn't make sense. IMO it was a mistake to ever add the ability. But that ship has sailed. > I don't see a strong reason to introduce yet-another API when someone > can just call things in a loop. I don't agree at all. That requires callers to know the set of possible values that stats need to be reset for - which has grown over time. But nearly all the time the right thing to do is to reset *all* shared stats, not just some. > 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. That's not analoguous - in your example the caller by definition knows the set of wait events it wants to create. Introducing a batch API wouldn't change that. But in case of resetting all stats the caller does *not* inherently know the set of stats types. Greetings, Andres Freund