8.6. Dirty Pages Flushing
In addition to replacing victim pages, the checkpointer and background writer processes flush dirty pages to storage.
Both processes share the same function of flushing dirty pages but perform different roles and behaviors.
8.6.1. Checkpointer
The checkpointer process writes a checkpoint record to the WAL segment file and flushes dirty pages whenever checkpointing starts.
Section 9.7 describes checkpointing and its triggers.
8.6.2. Background Writer
The background writer mitigates the intensive I/O load associated with checkpointing. This process continuously and gradually flushes dirty pages with minimal impact on overall database activity.
By default, the background writer wakes every 200 msec (defined by bgwriter_delay) and flushes a maximum of bgwriter_lru_maxpages (default is 100 pages).
A key difference from the checkpointer is the selection of target pages. While the checkpointer writes all dirty pages, the background writer primarily targets pages where the usage_count is 0. This strategy minimizes write load by leaving frequently used, or “hot,” pages (those with a high usage_count) in memory, thus reducing the probability of repeated I/O operations.
In version 9.1 or earlier, the background writer regularly performed checkpoint processing.
In version 9.2, the checkpointer process was separated from the background writer process. The proposal titled “Separating bgwriter and checkpointer” explains the reasoning. Relevant excerpts follow:
Currently(in 2011) the bgwriter process performs both background writing, checkpointing and some other duties. This means that we can’t perform the final checkpoint fsync without stopping background writing, so there is a negative performance effect from doing both things in one process.
Additionally, our aim in 9.2 is to replace polling loops with latches for power reduction. The complexity of the bgwriter loops is high and it seems unlikely to come up with a clean approach using latches.
(snip)