io_method

Definition PG 18 manual

Selects the method for executing asynchronous I/O. Possible values are:

The default is worker.

This parameter can only be set at server start.

How it works

worker sends eligible I/O through dedicated I/O worker processes; io_uring uses Linux io_uring and requires a build with liburing support; sync performs asynchronous-eligible operations synchronously. The upstream default is worker.

The PG18 AIO subsystem allows backends to queue multiple reads and can improve sequential scans, bitmap heap scans, vacuum, and other supported operations. It does not make every PostgreSQL I/O path asynchronous.

io_workers matters only when worker is selected. io_max_concurrency and the I/O combine limits control different dimensions of queue depth and request size, so method selection should be evaluated with them and with the storage stack.

Operational considerations

The parameter does not exist before PostgreSQL 18.

Changing it requires a server restart.

io_uring requires operating-system and build support; the enum value alone does not provide that support.

io_workers has no effect unless io_method=worker.

AIO benefits only eligible paths and cannot compensate for an overloaded or poorly configured storage layer.

Workload guidance

OLAP: Sequential and bitmap-heavy analytical workloads are promising AIO candidates. Benchmark worker and io_uring with realistic scan concurrency, not just a single cold scan.

OLTP: Use worker as the compatibility baseline. Test io_uring only on a verified build and kernel, and keep it only if representative concurrent latency improves without destabilizing the storage queue.

SMALL: Worker is a safe default; sync can be a diagnostic fallback when worker overhead or platform constraints matter. Avoid spending scarce processes on excessive io_workers.