Check parallel query capacity and current worker usage

Command

-- Parallel worker pool settings
SELECT name, current_setting(name) AS value
FROM pg_settings
WHERE name IN ('max_worker_processes', 'max_parallel_workers', 'max_parallel_workers_per_gather',
               'max_parallel_maintenance_workers', 'parallel_setup_cost', 'parallel_tuple_cost',
               'min_parallel_table_scan_size', 'min_parallel_index_scan_size')
ORDER BY name;

-- Queries currently running in parallel and their worker counts
SELECT a.pid AS leader_pid,
       count(w.pid) AS workers_running,
       current_setting('max_parallel_workers')::int AS max_parallel_workers,
       now() - a.query_start AS runtime,
       left(a.query, 80) AS query
FROM pg_stat_activity a
JOIN pg_stat_activity w ON w.leader_pid = a.pid AND w.pid <> a.pid
GROUP BY a.pid, a.query_start, a.query
ORDER BY workers_running DESC;

-- Pin / reset the planned worker count for a single table
ALTER TABLE orders SET (parallel_workers = 4);
ALTER TABLE orders RESET (parallel_workers);

What it does

Shows parallel query limits and how many parallel workers each leader process is using right now; demonstrates the per-table worker count setting.

When to use it

When analytic queries are slower than expected, the plan shows 'Workers Planned' > 'Workers Launched', or CPU cores sit idle.

Caution

max_parallel_workers is capped by max_worker_processes (restart required), and that pool is shared with logical replication workers and other background workers. In OLTP, a high max_parallel_workers_per_gather saturates CPU under concurrency; each worker also uses its own work_mem. Queries that write data or lock rows (except CREATE TABLE AS / SELECT INTO), cursors and queries calling PARALLEL UNSAFE functions do not get parallel plans. ALTER TABLE ... SET (parallel_workers) takes a brief ShareUpdateExclusiveLock.