Parameter · Write-Ahead Log / Recovery

recovery_prefetch

Prefetch referenced blocks during recovery. Look ahead in the WAL to find references to uncached data.

Default: try
Type: enum
Values: off · on · try
Applies: Reload

In plain words

During crash recovery or on a standby, replay often has to read data pages from disk one at a time, which is slow. With prefetching, PostgreSQL looks ahead in the WAL and asks the operating system to start loading the pages it will soon need, so replay waits less. try (default) uses it when the OS supports it.

For DBAs and operators

Added in PostgreSQL 15. The startup process decodes WAL ahead of replay (up to wal_decode_buffer_size) and issues posix_fadvise(WILLNEED) for referenced blocks that are not in shared buffers, with at most maintenance_io_concurrency reads in flight. Blocks covered by a full-page image, or new pages, are skipped.

on errors at startup if the platform lacks support, try silently falls back, off disables.
Biggest gains: standbys with a working set larger than shared_buffers and high-latency storage (network disks, cloud volumes), which otherwise show replay lag even when the primary is fine.

SELECT prefetch, hit, skip_fpw, skip_init, skip_new, skip_rep, wal_distance, block_distance, io_depth
  FROM pg_stat_recovery_prefetch;

How to change it

Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().

See it in context

Startup process Crash recovery Asynchronous I/O

Related parameters

wal_decode_buffer_size maintenance_io_concurrency hot_standby

All Write-Ahead Log parameters