Re: [PATCH] Add features to pg_stat_statements
От | Seino Yuki |
---|---|
Тема | Re: [PATCH] Add features to pg_stat_statements |
Дата | |
Msg-id | 2f749a3bd1b49f1d282abf59619fe1f5@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Add features to pg_stat_statements (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: [PATCH] Add features to pg_stat_statements
|
Список | 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,
Вложения
В списке pgsql-hackers по дате отправления: