effective_io_concurrency

Definition PG 18 manual

Sets the number of concurrent storage I/O operations that PostgreSQL expects can be executed simultaneously. Raising this value will increase the number of I/O operations that any individual PostgreSQL session attempts to initiate in parallel. The allowed range is 1 to 1000, or 0 to disable issuance of asynchronous I/O requests. The default is 16.

Higher values will have the most impact on higher latency storage where queries otherwise experience noticeable I/O stalls and on devices with high IOPs. Unnecessarily high values may increase I/O latency for all queries on the system.

On systems with prefetch advice support, effective_io_concurrency also controls the prefetch distance.

This value can be overridden for tables in a particular tablespace by setting the tablespace parameter of the same name (see ALTER TABLESPACE).

How it works

effective_io_concurrency tells one session how much storage concurrency it should try to exploit; it is not a cluster-wide queue cap. A tablespace option of the same name can override the session setting for data on that storage.

In PG10–17 it mainly controls prefetch distance for supported paths and platforms. The measured Linux-Docker boot value is 1, but unsupported platforms without effective posix_fadvise used 0 as the default; that platform condition must accompany any historical default claim.

PostgreSQL 18 integrates the setting with core asynchronous I/O, uses a boot default of 16, and allows 0 to disable asynchronous requests governed by this target. io_max_concurrency remains the separate per-process execution ceiling, and combine limits control bytes per request.

Operational considerations

Treating this per-session target as a cluster-wide cap; many sessions can multiply outstanding I/O.

Calling 1 the unconditional PG10–17 upstream default even though unsupported platforms defaulted to 0.

Applying PG18 AIO behavior to older releases that used the setting chiefly for prefetch advice.

Using one global value for mixed-storage tablespaces instead of considering tablespace overrides.

Raising the target until device queueing increases latency for every session.

Workload guidance

OLAP: Analytical scans and bitmap heap scans are stronger candidates for higher values. Benchmark sustained throughput and tail latency together, especially on network or high-IOPS storage.

OLTP: Start conservatively and measure read latency under concurrency. Fast point queries often gain less than bitmap or scan-heavy workloads, while a very high per-session value can multiply queue depth at high connection counts.

SMALL: Use the PG18 default or a modest value unless measurements show I/O stalls. A value of 200 is rarely justified on a small host merely because the disk is labeled SSD.