Parameter · Resource Usage / Worker Processes
max_parallel_workers_per_gather
Sets the maximum number of parallel processes per executor node.
- Default:
2 - Type: integer
- Range: 0 … 1024
- Applies: Session (any user)
In plain words
How many helper processes one query step may ask for. With the default 2, a big scan can be done by the session plus two workers. 0 turns parallel query off.
For DBAs and operators
The planner chooses a worker count per Gather / Gather Merge based on table size (min_parallel_table_scan_size, one more worker each time the table triples) and this cap; per-table override: ALTER TABLE t SET (parallel_workers = 8). At run time the workers may not be available (see max_parallel_workers), in which case the query runs with fewer.
Resources multiply: each worker is a full process with its own work_mem allowances, CPU and I/O. For OLTP with many concurrent short queries, 0–2 is reasonable; for analytics on many cores, 4–8 per query. Set it per role or per session for reporting jobs rather than globally. Parallel query is not used for queries that write data (except CREATE TABLE AS / SELECT INTO / REFRESH MATERIALIZED VIEW), inside cursors, or for functions marked PARALLEL UNSAFE.
EXPLAIN (ANALYZE) SELECT count(*) FROM big;
-- Gather Workers Planned: 2 Workers Launched: 2How to change it
Any user can change it for their session with SET.
See it in context
Parallel query Parallel and background workers Local (per-backend) memory
Related parameters
max_parallel_workers max_worker_processes parallel_setup_cost parallel_tuple_cost min_parallel_table_scan_size parallel_leader_participation