Re: Add new option 'all' to pg_stat_reset_shared() - Mailing list pgsql-hackers

From torikoshia
Subject Re: Add new option 'all' to pg_stat_reset_shared()
Date
Msg-id 62d8244b05557a91e25914c02607b493@oss.nttdata.com
Whole thread Raw
In response to Re: Add new option 'all' to pg_stat_reset_shared()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add new option 'all' to pg_stat_reset_shared()
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: meson documentation build open issues
Next
From: Michael Paquier
Date:
Subject: Re: ensure, not insure