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 по дате отправления:

Предыдущее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: Disable WAL logging to speed up data loading
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: warn_unused_results