On Wed, Dec 23, 2015 at 10:37 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> Hmmm. Let us try with both hands:
>
> AFAICR with xlog-triggered checkpoints, the checkpointer progress is
> measured with respect to the size of the WAL file, which does not grow
> linearly in time for the reason you pointed above (a lot of FPW at the
> beginning, less in the end). As the WAL file is growing quickly, the
> checkpointer thinks that it is late and that it has some catchup to do, so
> it will start to try writing quickly as well. There is a double whammy as
> both are writing more, and are probably not succeeding.
>
> For time triggered checkpoints, the WAL file gets filled up *but* the
> checkpointer load is balanced against time. This is a "simple" whammy, where
> the checkpointer uses IO bandwith which is needed for the WAL, and it could
> wait a little bit because the WAL will need less later, but it is not trying
> to catch up by even writing more, so the load shifting needed in this case
> is not the same as the previous case.
I see your point, but this isn't a function of what triggered the
checkpoint. It's a function of how we measure whether the
already-triggered checkpoint is on schedule - we may be behind either
because of time, or because of xlog, or both.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company