From: | Seino Yuki <seinoyu(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] Add features to pg_stat_statements |
Date: | 2020-11-09 09:02:53 |
Message-ID: | 050fd52dcddac965ad24a636c25a5611@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
pg_stat_statements_info.patch | text/x-diff | 12.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2020-11-09 09:31:10 | Re: logical streaming of xacts via test_decoding is broken |
Previous Message | Tang, Haiying | 2020-11-09 08:39:29 | Useless string ouput in error message |