min_parallel_index_scan_size

Definition PG 18 manual

Sets the minimum amount of index data that must be scanned in order for a parallel scan to be considered. Note that a parallel index scan typically won't touch the entire index; it is the number of pages which the planner believes will actually be touched by the scan which is relevant. This parameter is also used to decide whether a particular index can participate in a parallel vacuum. See VACUUM. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The default is 512 kilobytes (512kB).

How it works

min_parallel_index_scan_size is a planner eligibility floor: parallel scan paths are not considered unless index pages estimated to be visited reaches the configured size.

Crossing this floor does not guarantee a parallel plan. The planner still compares costs, checks parallel safety, and requests workers subject to max_parallel_workers_per_gather and the cluster worker pools.

The index threshold also participates in deciding whether an index can be vacuumed in parallel. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Operational considerations

Assuming the threshold caps actual bytes read; it only controls planner eligibility.

Expecting a parallel plan merely because the size estimate crosses the threshold.

Lowering it without budgeting workers and per-node memory under concurrency.

Comparing the raw numeric value without applying its 8kB block unit.

Workload guidance

OLAP: Keep the upstream threshold unless small but expensive scans are wrongly excluded. Lowering min_parallel_index_scan_size can raise planning and worker overhead when many queries run concurrently.

OLTP: A higher min_parallel_index_scan_size can reduce parallel startup on short OLTP scans, but confirm that reports and maintenance do not regress.

SMALL: Prefer a conservative or higher threshold on a small host where worker startup and memory contention dominate. Coordinate it with max_parallel_workers_per_gather rather than tuning it alone.