Re: Add new option 'all' to pg_stat_reset_shared()
От | Bharath Rupireddy |
---|---|
Тема | Re: Add new option 'all' to pg_stat_reset_shared() |
Дата | |
Msg-id | CALj2ACXQTKMYL-aYKM=XObQ27wyD3V2yRGeF1z=jJN7vptgNgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add new option 'all' to pg_stat_reset_shared() (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Add new option 'all' to pg_stat_reset_shared()
Re: Add new option 'all' to pg_stat_reset_shared() |
Список | pgsql-hackers |
On Wed, Nov 1, 2023 at 4:24 AM Michael Paquier <michael@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. > > 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
В списке pgsql-hackers по дате отправления: