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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Add new option 'all' to pg_stat_reset_shared()
Дата
Msg-id ZVCEvjc_uGo6tEA9@paquier.xyz
обсуждение исходный текст
Ответ на Re: Add new option 'all' to pg_stat_reset_shared()  (torikoshia <torikoshia@oss.nttdata.com>)
Ответы Re: Add new option 'all' to pg_stat_reset_shared()  (torikoshia <torikoshia@oss.nttdata.com>)
Список pgsql-hackers
On Fri, Nov 10, 2023 at 08:32:34PM +0900, torikoshia wrote:
> On 2023-11-10 13:18, Andres Freund wrote:
>> I see no reason to not include slrus. We should never have added the
>> ability to reset them individually, particularly not without a use
>> case - I couldn't find one skimming some discussion. And what's the
>> point in not allowing to reset them via pg_stat_reset_shared()?
>
> When including SLRUs, do you think it's better to add 'slrus' argument which
> enables pg_stat_reset_shared() to reset all SLRUs?

I understand that Andres says that he'd be OK with a addition of a
'slru' option in pg_stat_reset_shared(), as well as including SLRUs in
the resets if everything should be wiped.

28cac71bd368 is around since 13~, so changing pg_stat_reset_slru() or
removing it could impact existing applications, so there's little
benefit in changing it at this stage.  Let it be itself.

> As described above, since SLRUs cannot be reset by pg_stat_reset_shared(), I
> feel a bit uncomfortable to delete it all together.

That would be only effective if NULL is given to the function to reset
everything, which is OK IMO, because this is a shared stats.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Add new option 'all' to pg_stat_reset_shared()
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Parallel CREATE INDEX for BRIN indexes