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

From Stephen Frost
Subject Re: Change default of checkpoint_completion_target
Date
Msg-id 20210113221038.GG27507@tamriel.snowman.net
Whole thread Raw
In response to Re: Change default of checkpoint_completion_target  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Change default of checkpoint_completion_target  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Greetings,

* Stephen Frost (sfrost@snowman.net) wrote:
> * Alvaro Herrera (alvherre@alvh.no-ip.org) wrote:
> > On 2020-Dec-10, Stephen Frost wrote:
> > > * Laurenz Albe (laurenz.albe@cybertec.at) wrote:
> > > > On Tue, 2020-12-08 at 17:29 +0000, Bossart, Nathan wrote:
> > > > > +1 to setting checkpoint_completion_target to 0.9 by default.
> > > >
> > > > +1 for changing the default or getting rid of it, as Tom suggested.
> > >
> > > Attached is a patch to change it from a GUC to a compile-time #define
> > > which is set to 0.9, with accompanying documentation updates.
> >
> > I think we should leave a doc stub or at least an <indexterm>, to let
> > people know the GUC has been removed rather than just making it
> > completely invisible.  (Maybe piggyback on the stuff in [1]?)
> >
> > [1] https://postgr.es/m/CAGRY4nyA=jmBNa4LVwgGO1GyO-RnFmfkesddpT_uO+3=mot8DA@mail.gmail.com
>
> Yes, I agree, and am involved in that thread as well- currently waiting
> feedback from others about the proposed approach.

I've tried to push that forward.  I'm happy to update this patch once
we've got agreement to move forward on that, to wit, adding to an
'obsolete' section in the documentation information about this
particular GUC and how it's been removed due to not being sensible or
necessary to continue to have.

> Getting a few more people looking at that thread and commenting on it
> would really help us be able to move forward.

This is still the case though..

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [DOC] Document concurrent index builds waiting on each other
Next
From: Thomas Munro
Date:
Subject: Re: pg_preadv() and pg_pwritev()