Re: [PATCH] Add features to pg_stat_statements

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

In response to

Responses

Browse pgsql-hackers by date

  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