maintenance_io_concurrency

maintenance_io_concurrency — A variant of “effective_io_concurrency” that is used for maintenance work. Observed in PG13–19 Beta 3; its last measured boot default is 16 in PG19 Beta 3, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “A variant of “effective_io_concurrency” that is used for maintenance work.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value0 – 1000: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueResource Usage / I/O: Upstream classification
Latest boot value , Value16: 16

Lifecycle

Fact	Value
First observed	PG13
Present in	PG13–19 Beta 3
Removed in	No
Introduction commit	`fc34b0d9de27` — Introduce a maintenance_io_concurrency setting.
Commit date	2020-03-16
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG13–17	`10`	—	10
PG18–19 Beta 3	`16`	—	16

How it works

maintenance_io_concurrency is the per-maintenance-operation target for storage concurrency used by work performed on behalf of many clients. A tablespace option of the same name can override it for that storage; it is neither a cluster-wide device cap nor a memory allocation.

In PG13–17 it chiefly controls maintenance prefetch on supported systems. The measured Linux-Docker boot value is 10, while unsupported platforms without effective prefetch-advice support defaulted to 0; those releases do not have the PG18 core-AIO execution model.

PostgreSQL 18 integrates the target with core AIO and uses a boot default of 16. io_max_concurrency separately clamps simultaneous execution by one process, io_method chooses the execution mechanism, and combine limits control bytes per request. Its user context permits scoped runtime changes.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	For PG13–17, tune this as a maintenance-prefetch target only on supported storage; for PG18, tune it as an AIO concurrency target. Measure foreground tail latency while VACUUM or other eligible maintenance runs, and use a tablespace override for heterogeneous storage.
OLAP	Higher maintenance concurrency can shorten eligible scans or vacuum work on high-latency, high-IOPS storage, but it can also deepen the queue seen by analytical queries. Benchmark maintenance completion time and mixed-workload latency together; it does not change request size.
Small nodes	Use the version- and platform-appropriate default unless maintenance is demonstrably I/O-stalled. A small host can saturate storage with a low target, so do not copy Pigsty’s SSD value 100 without measurement.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`100`	different	`100`
OLAP	`100`	different	`100`
CRIT	`100`	different	`100`
TINY	`100`	different	`100`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG13–19 Beta 3 = 100 (dcs); OLAP: PG13–19 Beta 3 = 100 (dcs); CRIT: PG13–19 Beta 3 = 100 (dcs); TINY: PG13–19 Beta 3 = 100 (dcs). Advice, pending human review — Editorial inference: the template asks SSD maintenance to exploit more prefetch/AIO concurrency, but the value is a target per maintenance operation and must be validated against foreground latency.

Common pitfalls

Calling 10 the unconditional PG13–17 default when unsupported platforms used 0.
Back-projecting PG18 core-AIO semantics into PG13–17 prefetch behavior.
Treating the per-operation target as a cluster or device-wide cap.
Confusing concurrency with io_combine_limit’s bytes-per-request dimension.
Using one value across tablespaces with materially different storage.

effective_io_concurrency · io_method · io_max_concurrency · io_combine_limit · vacuum_buffer_usage_limit