Re: [PATCH] Add features to pg_stat_statements - Mailing list pgsql-hackers

From Seino Yuki
Subject Re: [PATCH] Add features to pg_stat_statements
Date
Msg-id 050fd52dcddac965ad24a636c25a5611@oss.nttdata.com
Whole thread Raw
In response to Re: [PATCH] Add features to pg_stat_statements  (Seino Yuki <seinoyu@oss.nttdata.com>)
Responses Re: [PATCH] Add features to pg_stat_statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
2020-11-09 15:39 に Seino Yuki さんは書きました:
>>> 
>>> However, let me confirm the following.
>>>> Is this information really useful?
>>>> If there is no valid use case for this, I'd like to drop it.
>>>> Thought?
>>> 
>>> I thought it would be easy for users to see at a glance that if there 
>>> is a case I assumed,
>>> if the last modified date and time is old, there is no need to adjust 
>>> at all, and if the
>>> last modified date and time is recent, it would be easy for users to 
>>> understand that the
>>> parameters need to be adjusted.
>>> What do you think?
>> 
>> Even without the last deallocation timestamp, you can presume
>> when the deallocation of entries happened by periodically monitoring
>> the total number of deallocations and seeing those history. Or IMO
>> it's better to log whenever the deallocation happens as proposed 
>> upthread.
>> Then you can easily check the history of occurrences of deallocations
>> from the log file.
>> 
>> Regards,
> 
> +1.I think you should output the deallocation history to the log as 
> well.
> 
> In light of the above, I've posted a patch that reflects the points 
> made.
> 
> Regards,

Sorry. There was a typo in the documentation correction.
I'll post a patch to fix it.

Regards,
Attachment

pgsql-hackers by date:

Previous
From: "Tang, Haiying"
Date:
Subject: Useless string ouput in error message
Next
From: Dilip Kumar
Date:
Subject: Re: logical streaming of xacts via test_decoding is broken