io_worker_launch_interval

Definition PG 20 devel manual

Sets the minimum time before another I/O worker can be launched. This avoids creating too many for an unsustained burst of activity. The default is 100ms. This parameter can only be set in the postgresql.conf file or on the server command line.

Only has an effect if io_method is set to worker.

How it works

PostgreSQL describes io_worker_launch_interval as follows: “Minimum time before launching a new I/O worker process, for io_method=worker.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

These controls govern the elastic background-worker pool used only when io_method is worker. io_min_workers keeps warm capacity, io_max_workers caps the pool, io_worker_launch_interval damps short bursts, and io_worker_idle_timeout lets unused workers retire; they do not raise a backend's separate io_max_concurrency ceiling.

Read it together with io_min_workers, io_max_workers, io_worker_idle_timeout, io_method. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Operational considerations

Treating the measured boot_val for io_worker_launch_interval as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports sighup context.

Changing this setting in isolation without checking the linked limits, observability, and rollback path.

Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Workload guidance

OLAP: Use representative scans, prefetch, and spill phases. Increase concurrency or worker capacity only while throughput rises without unacceptable CPU overhead, memory pressure, or storage saturation.

OLTP: Benchmark with the production storage stack and concurrency. Optimize tail latency and queue depth, not only average throughput, and retain capacity for WAL, checkpoints, and foreground reads.

SMALL: Prefer auto or the upstream worker limits. Validate with pg_test_timing or I/O statistics as applicable; a larger pool on a small node can add context switching without useful parallelism.