The bgwriter has been responsible for two main activities: incremental
page cleaning and checkpointing.
We've worked out the code to smooth checkpointing, but that now means
we have periods where we do both page cleaning and checkpointing, and
other times when we do just page cleaning. That means the processing
loops are complex and that makes latch based processing more difficult
to introduce.
Moreover, when we perform fsyncs at the end of checkpoint we stop
doing pagecleaning.
I propose to introduce a new process dedicated to checkpointing,
leaving the bgwriter process to perform pagecleaning, if that is
requested. Note that on smaller systems the bgwriter process would not
even be required to exist, if page cleaning was not used.
This will simplify the code, so that checkpoint happens fairly cleanly
- and can then be extended in other ways. The checkpointer would be
the important process from a shutdown perspective.
It will also simplify the bgwriter, potentially allowing us to
consider that it performs other tasks, such as HOT vacuuming or hint
bit setting. Nothing added in first version, but this clears the way
to allow these things to be considered and prototyped.
So the likelihood is this change will improve performance of itself in
large systems, but the main benefit is code simplicity which is
required for a range of potential futures.
Are there objections to this work beginning?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services