8.6. Flushing Dirty Pages
In addition to replacing victim pages, the checkpointer and background writer processes flush dirty pages to storage. Both processes have the same function, flushing dirty pages, but they have different roles and behaviors.
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 when it begins.
The background writer’s role is to mitigate the intensive I/O load associated with checkpointing. The background writer 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 bgwriter_lru_maxpages (the default is 100 pages) at most.
A key difference from the checkpointer is that while the checkpointer writes all dirty pages, the background writer primarily targets pages where the usage_count is 0. This strategy allows the background writer to minimize write load by leaving frequently used, or “hot,” pages (those with a high usage_count) in memory, thus reducing the chance of repeated I/O operations.
In versions 9.1 or earlier, background writer had regularly done the checkpoint processing.
In version 9.2, the checkpointer process has been separated from the background writer process. Since the reason is described in the proposal whose title is “Separating bgwriter and checkpointer”, the sentences from it are shown in the following.
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)