Parameter · Query Tuning / Planner Cost Constants
parallel_tuple_cost
Sets the planner's estimate of the cost of passing each tuple (row) from worker to leader backend.
- Default:
0.1 - Type: real
- Range: 0 … 1.79769e+308
- Applies: Session (any user)
In plain words
Workers hand their result rows to the leader process through shared memory queues. This is the price per row for that transfer. Queries that return many rows from workers look expensive, which is why parallelism shines for aggregates that send back only a few rows.
For DBAs and operators
Charged per row estimated to flow through a Gather or Gather Merge. With 0.1 per row (ten times cpu_tuple_cost), sending 1 million rows through Gather adds 100,000 to the cost, so the planner prefers plans where workers do the filtering and partial aggregation and only send a few rows upward (Partial Aggregate → Finalize Aggregate).
The animation shows this: with few matching rows, the parallel scan wins easily; with 60% of rows going through the leader, the transfer cost eats the gain. The leader is often the bottleneck when it must both run its share of the scan and read all worker queues; parallel_leader_participation = off is sometimes tried in that case.
Lowering it encourages parallel plans that return many rows; raising it restricts parallelism to aggregation-style queries.
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_setup_cost cpu_tuple_cost max_parallel_workers_per_gather parallel_leader_participation