Re: should we enable log_checkpoints out of the box? - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: should we enable log_checkpoints out of the box?
Date
Msg-id 4144af5e-b4fc-22e7-0744-378c9d374bf1@enterprisedb.com
Whole thread Raw
In response to Re: should we enable log_checkpoints out of the box?  (Andres Freund <andres@anarazel.de>)
Responses Re: should we enable log_checkpoints out of the box?
List pgsql-hackers
On 10/31/21 21:16, Andres Freund wrote:
> Hi,
> 
> On 2021-10-31 15:43:57 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> On 2021-10-31 10:59:19 -0400, Tom Lane wrote:
>>>> No DBA would be likely to consider it as anything but log spam.
>>
>>> I don't agree at all. No postgres instance should be run without
>>> log_checkpoints enabled. Performance is poor if checkpoints are
>>> triggered by anything but time, and that can only be diagnosed if
>>> log_checkpoints is on.
>>
>> This is complete nonsense.
> 
> Shrug. It's based on many years of doing or being around people doing
> postgres support escalation shifts. And it's not like log_checkpoints
> incurs meaningful overhead or causes that much log volume.
> 

Yeah. In tuned instances the checkpoints happen fairly infrequently most 
of the time (occasional batch loads being an exception, etc.), so the 
extra log traffic should be fairly negligible. And it's not like we can 
make checkpointer infinitely smart - sometimes the cause is a change in 
the workload etc.

OTOH most of this data (# of timed/xlog checkpoints, buffers written by 
checkpointer etc.) is available in the pg_stat_bgwriter view, and people 
generally have monitoring these days.

I don't have a strong opinion on changing the default - we generally 
recommend changing it, and we'll keep doing it, but it's usually part of 
various other recommendations so this one tweak does not eliminate that.


regards

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: inefficient loop in StandbyReleaseLockList()
Next
From: Tomas Vondra
Date:
Subject: Re: Added schema level support for publication.