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 06:39:05 |
Message-ID: | 2f749a3bd1b49f1d282abf59619fe1f5@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>
>> 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,
Attachment | Content-Type | Size |
---|---|---|
pg_stat_statements_info.patch | text/x-diff | 12.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-11-09 06:56:06 | Re: warn_unused_results |
Previous Message | osumi.takamichi@fujitsu.com | 2020-11-09 06:30:55 | RE: Disable WAL logging to speed up data loading |