Re: Change default of checkpoint_completion_target

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Change default of checkpoint_completion_target
Дата
Msg-id 9cbef4ca-807f-e65a-08bf-4f376aecea41@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Change default of checkpoint_completion_target  (Andres Freund <andres@anarazel.de>)
Ответы Re: Change default of checkpoint_completion_target  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 1/15/21 10:51 PM, Andres Freund wrote:
> Hi,
> 
> On 2020-12-08 12:41:35 -0500, Tom Lane wrote:
>> FWIW, I kind of like the idea of getting rid of it completely.
>> Is there really ever a good reason to set it to something different
>> than that?  If not, well, we have too many GUCs already, and each
>> of them carries nonzero performance, documentation, and maintenance
>> overhead.
> 
> I like the idea of getting rid of it too, but I think we should consider
> evaluating the concrete hard-coded value a bit more careful than just
> going for 0.9 based on some old recommendations in the docs. It not
> being changeable afterwards...
> 
> I think it might be a good idea to immediately change the default to
> 0.9, and concurrently try to evaluate whether it's really the best value
> (vs 0.95, 1 or ...).
> 
> FWIW I have seen a few cases in the past where setting the target to
> something very small helped, but I think that was mostly because we
> didn't yet tell the kernel to flush dirty data more aggressively.
> 

Yeah. The flushing probably makes that mostly unnecessary, but we still
allow disabling that. I'm not really convinced replacing it with a
compile-time #define is a good idea, exactly because it can't be changed
if needed.

As for the exact value, maybe the right solution is to make it dynamic.
The usual approach is to leave "enough time" for the kernel to flush
dirty data, so we could say 60 seconds and calculate the exact target
depending on the checkpoint_timeout.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Key management with tests
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Key management with tests