Re: [PATCH] Add features to pg_stat_statements
Yuki Seino <seinoyu@oss.nttdata.com>
From: Seino Yuki <seinoyu@oss.nttdata.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-11-09T06:39:05Z
Lists: pgsql-hackers
Attachments
- pg_stat_statements_info.patch (text/x-diff) patch
>> >> 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,
Commits
-
pg_stat_statements: Track number of times pgss entries were deallocated.
- 9fbc3f318d03 14.0 landed