Parallel Query: Workers Planned 0 despite enabled configuration

Answer

When Workers Planned: 0 appears, the planner has decided that the cost of launching and coordinating workers outweighs the potential speed‑up for that query. Even if max_parallel_workers and max_parallel_workers_per_gather allow concurrency, PostgreSQL’s cost model may still prefer a serial plan.

Cost‑Based Decision

The planner compares the estimated cost of a serial plan with that of a parallel plan. For a Gather node the inequality that must hold for workers to be planned is:

serial_cost - parallel_cost > parallel_setup_cost * workers + parallel_tuple_cost * estimated_rows

If the estimated number of rows is low, or the operation is cheap, the right‑hand side can dominate, causing the planner to choose 0 workers. The key parameters involved are:

• parallel_setup_cost – fixed cost of starting workers.
• parallel_tuple_cost – per‑tuple cost of master‑worker communication.
• max_parallel_workers / max_parallel_workers_per_gather – limits on worker count.

Practical Verification

1. Check current settings:

   SHOW parallel_setup_cost;
   SHOW parallel_tuple_cost;
   SHOW max_parallel_workers;
   SHOW max_parallel_workers_per_gather;
   

2. Run an explanatory plan:

   EXPLAIN (ANALYZE, BUFFERS, COSTS) SELECT …;
   

   Inspect Workers Planned and the cost columns.

3. Force a parallel plan for testing:

   SET parallel_setup_cost = 0;
   SET parallel_tuple_cost = 0;
   EXPLAIN (ANALYZE, BUFFERS, COSTS) SELECT …;
   

   If workers appear, the original decision was cost‑driven.

4. Adjust limits if needed:

   SET max_parallel_workers_per_gather = N;
   

Missing Diagnostic Detail

To refine the recommendation, I need the estimated row count for the operation that could use parallel workers (shown as Rows in the EXPLAIN output). This figure determines whether the planner expects a benefit from parallelism.

Please run EXPLAIN (ANALYZE, BUFFERS, COSTS) SELECT …; and share the estimated row count for that operation.