Kapazität für Parallel Query und aktuelle Worker-Nutzung prüfen

Befehl

-- 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);

Was es tut

Zeigt die Limits für Parallel Query und wie viele parallele Worker jeder Leader-Prozess gerade nutzt; demonstriert die Einstellung der Worker-Anzahl je Tabelle.

Wann einsetzen

Wenn analytische Abfragen langsamer sind als erwartet, der Plan 'Workers Planned' > 'Workers Launched' zeigt oder CPU-Kerne ungenutzt sind.

Vorsicht

max_parallel_workers wird durch max_worker_processes begrenzt (Neustart erforderlich), und dieser Pool wird mit Workern der logischen Replikation und anderen Background Workern geteilt. In OLTP sättigt ein hoher max_parallel_workers_per_gather unter Parallelität die CPU; jeder Worker nutzt außerdem sein eigenes work_mem. Abfragen, die Daten schreiben oder Zeilen sperren (außer CREATE TABLE AS / SELECT INTO), Cursors und Abfragen mit PARALLEL-UNSAFE-Funktionen erhalten keine parallelen Pläne. ALTER TABLE ... SET (parallel_workers) nimmt kurz einen ShareUpdateExclusiveLock.