Re: Add new option 'all' to pg_stat_reset_shared()
От | torikoshia |
---|---|
Тема | Re: Add new option 'all' to pg_stat_reset_shared() |
Дата | |
Msg-id | 62d8244b05557a91e25914c02607b493@oss.nttdata.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()
|
Список | pgsql-hackers |
On 2023-11-09 08:58, Michael Paquier wrote: > On Wed, Nov 08, 2023 at 02:15:24PM +0530, Bharath Rupireddy wrote: >> On Wed, Nov 8, 2023 at 9:43 AM Andres Freund <andres@anarazel.de> >> wrote: >>> It's not like oids are a precious resource. It's a more confusing API >>> to have >>> to have to specify a NULL as an argument than not having to do so. If >>> we >>> really want to avoid a separate oid, a more sensible path would be to >>> add a >>> default argument to pg_stat_reset_slru() (by doing a CREATE OR >>> REPLACE in >>> system_functions.sql). >> >> +1. Attached the patch. >> >> -- Test that multiple SLRUs are reset when no specific SLRU provided >> to reset function >> -SELECT pg_stat_reset_slru(NULL); >> +SELECT pg_stat_reset_slru(); > > For the SLRU part, why not. > > Hmm. What's the final plan for pg_stat_reset_shared(), then? An > equivalent that calls a series of pgstat_reset_of_kind()? Sorry for late reply and thanks for the feedbacks everyone. As your 1st suggestion, I think "calls a series of pgstat_reset_of_kind()" would be enough. I am a little concerned about that the reset time is not the same and that GetCurrentTimestamp() is called multiple times, but I think it would be acceptable because the function is probably not used that often and the reset time is not atomic in practice. I'll attach the patch. -- Regards, -- Atsushi Torikoshi NTT DATA Group Corporation
В списке pgsql-hackers по дате отправления: