Parameter · Query Tuning / Planner Cost Constants
parallel_setup_cost
Sets the planner's estimate of the cost of starting up worker processes for parallel query.
- Default:
1000 - Type: real
- Range: 0 … 1.79769e+308
- Applies: Session (any user)
In plain words
Starting worker processes and setting up shared memory for them takes time. This is the fixed price the planner adds to any parallel plan. Higher values keep small queries serial; lower values make parallelism kick in sooner.
For DBAs and operators
Added once to every Gather or Gather Merge path. With the default 1000, a parallel plan must save more than 1000 cost units over the serial plan to win, which mostly excludes queries that are cheap anyway. Starting a worker means forking a background worker from the postmaster, attaching dynamic shared memory and serializing the plan; on a busy system that can take milliseconds.
Lowering it (for example to 100) on OLAP systems makes medium-sized queries go parallel. Raising it on OLTP systems prevents many short queries from each grabbing workers. Whether workers are actually available at run time is a separate matter: EXPLAIN ANALYZE shows Workers Planned: 2 vs Workers Launched: 0 when max_parallel_workers or max_worker_processes slots are exhausted.
For testing, SET parallel_setup_cost = 0; SET parallel_tuple_cost = 0; together with min_parallel_table_scan_size = 0 makes the planner pick parallel plans almost wherever they are possible (debug_parallel_query is the developer option that really forces them).
How to change it
Any user can change it for their session with SET.
See it in context
Parallel query Parallel and background workers Planner cost model
Related parameters
parallel_tuple_cost max_parallel_workers_per_gather min_parallel_table_scan_size max_parallel_workers