recovery_prefetch

Definition PG 18 manual

Whether to try to prefetch blocks that are referenced in the WAL that are not yet in the buffer pool, during recovery. Valid values are off, on and try (the default). The setting try enables prefetching only if the operating system provides support for issuing read-ahead advice.

Prefetching blocks that will soon be needed can reduce I/O wait times during recovery with some workloads. See also the wal_decode_buffer_size and maintenance_io_concurrency settings, which limit prefetching activity.

How it works

Prefetch referenced blocks during recovery. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

During recovery, PostgreSQL can issue read-ahead advice for blocks identified by WAL before replay needs them. try enables it only when the operating system supports the required advice; wal_decode_buffer_size and maintenance_io_concurrency bound how far and how much it can prefetch.

Monitor and change recovery_prefetch together with wal_decode_buffer_size, maintenance_io_concurrency, effective_io_concurrency. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Assuming try always enables prefetch even when the operating system lacks the required read-ahead advice.

Increasing look-ahead without considering wal_decode_buffer_size and maintenance_io_concurrency.

Letting recovery prefetch compete with queries on a hot standby for cache and I/O queue depth.

Benchmarking sequential recovery only, where block prefetch may provide little benefit.

Workload guidance

OLAP: Large data with slow random reads may benefit more, but excess prefetch competes with query I/O and cache. Test crash recovery and a query-serving standby separately.

OLTP: Tune recovery_prefetch with recovery/standby catch-up benchmarks on production-like storage while observing replay I/O wait, cache behavior, and maintenance_io_concurrency. Keep the default without measured benefit.

SMALL: The default is usually sufficient. Do not spend scarce memory or I/O queue depth on a larger look-ahead window unless a recovery-time objective is demonstrably missed.