Re: Checkpoint throttling issues

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Checkpoint throttling issues
Date: 2015-10-20 08:32:44
Message-ID: CAA4eK1Ky6rf10wS_jx5-4U9+SS1aBwa7haN=9RQomBY8iZY3CA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 20, 2015 at 1:05 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
>
> Fabien COELHO wrote:
>
> > >4) It's a bit dubious to only pgstat_send_bgwriter() when on schedule.
> >
> > No opinion!
>
> My guess here, without looking, is that this was based on the idea of
> "oops, we're late here for the checkpoint, let's do as less work as
> possible to avoid getting even later", and thus skip some "unnecessary"
> tasks.
>

I also think thats what could be the reason for writing the code that way,
it seems to me that processing config file when not on schedule has
an advantage such that if user has modified checkpoint related parameters
(like checkpoint_completion_target), that could improve the checkpoint
behaviour. Now there could be some negative impact of this change as
well if user changes full_page_writes parameter, as to process that, it
needs to write a WAL record which could be costly when the checkpoint is
not on schedule, but I think the odds of that are less, so there doesn't
seem to be any harm in changing this behaviour.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Syed, Rahila 2015-10-20 08:58:11 Re: [PROPOSAL] VACUUM Progress Checker.
Previous Message Amit Kapila 2015-10-20 07:35:42 Re: checkpointer continuous flushing