Whenever more than this amount of data has been written by the background writer, attempt to force the OS to issue these writes to the underlying storage.
At a glance
| Property | Value |
|---|---|
| Parameter | bgwriter_flush_after |
| Category | Resource Consumption |
| Default | 512kB |
| Value type | integer |
| Change scope | Reload (postgresql.conf, SIGHUP) |
| Available in | PostgreSQL 12, 13, 14, 15, 16, 17, 18, 19 (added in 12) |
What it does
Whenever more than this amount of data has been written by the background writer, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel’s page cache, reducing the likelihood of stalls when an fsync is issued at the end of a checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than shared_buffers, but smaller than the OS’s page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The valid range is between 0, which disables forced writeback, and 2MB. The default is 512kB on Linux, 0 elsewhere. (If BLCKSZ is not 8kB, the default and maximum values scale proportionally to it.) This parameter can only be set in the postgresql.conf file or on the server command line.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Set it in postgresql.conf (or with ALTER SYSTEM) and reload with SELECT pg_reload_conf(); or pg_ctl reload — no restart needed.
Inspect the current value and source with SHOW bgwriter_flush_after; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'bgwriter_flush_after';.
Tuning guidance
This parameter is rarely a performance lever. Leave it at the default unless you have a specific, documented reason to change it, change it on one session or one role/database first, and confirm the effect with pg_settings and your own measurements before rolling it out cluster-wide.