Re: Change default of checkpoint_completion_target - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Change default of checkpoint_completion_target
Date
Msg-id 9cbef4ca-807f-e65a-08bf-4f376aecea41@enterprisedb.com
Whole thread Raw
In response to Re: Change default of checkpoint_completion_target  (Andres Freund <andres@anarazel.de>)
Responses Re: Change default of checkpoint_completion_target  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Key management with tests
Next
From: "David G. Johnston"
Date:
Subject: Re: Key management with tests