Re: should we enable log_checkpoints out of the box?

On Sun, Oct 31, 2021 at 9:05 PM Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
wrote:

> On 10/31/21 21:16, Andres Freund wrote:
> > Hi,
> >
> > On 2021-10-31 15:43:57 -0400, Tom Lane wrote:
> >> Andres Freund <andres(at)anarazel(dot)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.
>

Yeah, I think you can get much of the data you need in pg_stat_bgwriter.
There is still some data that log_checkpoint gives you that the statistics
don't -- but maybe we should instead look at exposing that information in
pg_stat_bgwriter, rather than changing the default.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>