Vérifier la capacité de requêtes parallèles et l'utilisation actuelle des workers
PostgreSQLPerformancesCommande
-- 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);Ce que fait la commande
Affiche les limites des requêtes parallèles et combien de workers parallèles chaque processus leader utilise en ce moment ; illustre le réglage du nombre de workers par table.
Quand l'utiliser
Lorsque les requêtes analytiques sont plus lentes que prévu, que le plan montre 'Workers Planned' > 'Workers Launched', ou que des cœurs CPU restent inactifs.
Attention
max_parallel_workers est plafonné par max_worker_processes (redémarrage requis), et ce pool est partagé avec les workers de réplication logique et les autres background workers. En OLTP, un max_parallel_workers_per_gather élevé sature le CPU en cas de concurrence ; chaque worker utilise aussi son propre work_mem. Les requêtes qui écrivent des données ou verrouillent des lignes (sauf CREATE TABLE AS / SELECT INTO), les curseurs et les requêtes appelant des fonctions PARALLEL UNSAFE n'obtiennent pas de plan parallèle. ALTER TABLE ... SET (parallel_workers) prend un bref ShareUpdateExclusiveLock.
Voir aussi
- Trouver les requêtes les plus coûteuses (pg_stat_statements : temps total et moyen)
- Trouver les requêtes à l'origine des E/S disque, fichiers temporaires et WAL (pg_stat_statements)
- Réinitialiser les statistiques pg_stat_statements (toutes ou une seule requête)
- Journaliser les plans d'exécution des requêtes lentes avec auto_explain
- Lire un plan en profondeur avec EXPLAIN (ANALYZE, BUFFERS, SETTINGS, WAL)
- Détecter les régressions de plan par queryid (comparaison de snapshots pg_stat_statements)