ES011: Fewer parallel workers than planned

• Signal: Workers Launched lower than Workers Planned on a Gather or Gather Merge.
• Evidence: planned and launched workers.
• Action: the worker pool was exhausted. Review max_parallel_workers and max_worker_processes against the number of parallel queries running at once.

Example

The parallel_workers_not_launched scenario of the test corpus, captured on PostgreSQL 16: the plan asks for two workers but none can start because max_parallel_workers is 0.

SELECT count(*) FROM orders WHERE amount > 500;

Finalize Aggregate  (cost=3562.50..3562.51 rows=1 width=8) (actual time=29.513..29.603 rows=1 loops=1)
  Output: count(*)
  Buffers: shared hit=2417
  ->  Gather  (cost=3562.49..3562.50 rows=2 width=8) (actual time=29.508..29.598 rows=1 loops=1)
        Output: (PARTIAL count(*))
        Workers Planned: 2
        Workers Launched: 0
        Buffers: shared hit=2417
        ->  Partial Aggregate  (cost=3562.49..3562.50 rows=1 width=8) (actual time=29.234..29.235 rows=1 loops=1)
              Output: PARTIAL count(*)
              Buffers: shared hit=2417
              ->  Parallel Seq Scan on public.orders  (cost=0.00..3458.67 rows=41528 width=0) (actual time=0.015..24.602 rows=99998 loops=1)
                    Output: id, customer_id, status, created_at, amount, note
                    Filter: (orders.amount > '500'::numeric)
                    Rows Removed by Filter: 100002
                    Buffers: shared hit=2417
Settings: max_parallel_workers = '0', parallel_setup_cost = '0', parallel_tuple_cost = '0', min_parallel_table_scan_size = '0'
Planning:
  Buffers: shared hit=83
Planning Time: 0.329 ms
Execution Time: 29.642 ms

explainsql reports:

HIGH  ES011 Fewer parallel workers than planned
Gather started 0 of the 2 parallel workers it planned.
Workers planned: 2
Workers launched: 0
→ The pool of parallel workers was exhausted: check max_parallel_workers and max_worker_processes against the number of parallel queries running at once.

All rules