PostgreSQL 14 上的大表的基本計數，具有 64GB 記憶體和 20 個執行緒。存盤是一個 NVME 磁盤。
問題：
- 如何改進此選擇計數查詢的查詢？我應該對 Postgres 配置進行哪些優化？
- 計劃的工人是 4，但推出的工人是 0，這正常嗎？
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM public.product;
Finalize Aggregate (cost=2691545.69..2691545.70 rows=1 width=8) (actual time=330901.439..330902.951 rows=1 loops=1)
Buffers: shared hit=1963080 read=1140455 dirtied=1908 written=111146
I/O Timings: read=36692.273 write=6548.923
-> Gather (cost=2691545.27..2691545.68 rows=4 width=8) (actual time=330901.342..330902.861 rows=1 loops=1)
Workers Planned: 4
Workers Launched: 0
Buffers: shared hit=1963080 read=1140455 dirtied=1908 written=111146
I/O Timings: read=36692.273 write=6548.923
-> Partial Aggregate (cost=2690545.27..2690545.28 rows=1 width=8) (actual time=330898.747..330898.757 rows=1 loops=1)
Buffers: shared hit=1963080 read=1140455 dirtied=1908 written=111146
I/O Timings: read=36692.273 write=6548.923
-> Parallel Index Only Scan using points on products (cost=0.57..2634234.99 rows=22524114 width=0) (actual time=0.361..222958.361 rows=90993600 loops=1)
Heap Fetches: 46261956
Buffers: shared hit=1963080 read=1140455 dirtied=1908 written=111146
I/O Timings: read=36692.273 write=6548.923
Planning:
Buffers: shared hit=39 read=8
I/O Timings: read=0.398
Planning Time: 2.561 ms
JIT:
Functions: 4
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 0.691 ms, Inlining 104.789 ms, Optimization 24.169 ms, Emission 22.457 ms, Total 152.107 ms
Execution Time: 330999.777 ms
uj5u.com熱心網友回復：
計劃的工人是 4，但推出的工人是 0，這正常嗎？
當太多并發事務競爭有限數量的允許并行作業執行緒時，就會發生這種情況。手冊：
規劃器將考慮使用的后臺作業人員的數量最多限制為
max_parallel_workers_per_gather。可以同時存在的后臺作業人員總數受max_worker_processes和 的 限制max_parallel_workers。因此，并行查詢可能會以比計劃更少的作業人員運行，甚至根本沒有作業人員。最佳計劃可能取決于可用的作業人員數量，因此這可能會導致查詢性能不佳。如果這種情況經常發生，請考慮增加max_worker_processes，max_parallel_workers以便可以同時運行更多的作業人員，或者max_parallel_workers_per_gather減少作業人員，以便計劃程式請求更少的作業人員。
您還可以優化整體性能以釋放資源，或獲得更好的硬體（除了加速max_parallel_workers）。
還有什么令人煩惱的：
堆獲取：46261956
對于 90993600 行。這對于舒適來說太多了。僅索引掃描不應該執行那么多堆提取。
這兩種癥狀都表明大量并發寫入訪問（或長時間運行的事務占用資源并阻止autovacuum其作業）。調查一下，和/或調整表的每個表autovacuum設定，product使其更加積極，以便列統計資訊更有效并且可見性圖可以跟上。看：
- PostgreSQL 上的主動式自動清理
此外，對于中途有效的表統計，（極快！）估計可能就足夠了？看：
- 在 PostgreSQL 中發現表的行數的快速方法
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/353902.html