On Sun, Oct 31, 2021 at 9:05 PM Tomas Vondra <tomas.von...@enterprisedb.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 <and...@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. > 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/>
