我有一個很大的查詢，我正在嘗試分析以提高效率。我首先跑了EXPLAIN：
EXPLAIN
SELECT * FROM pop_allocation_sql.main_parcels_cb_intersects
WHERE parcel_id NOT IN (SELECT DISTINCT parcel_id::int
FROM pop_allocation_sql.main_bldgs_cb_intersects)
它在幾秒鐘內回傳以下內容：
Gather (cost=20506897.97..3330358572517.40 rows=40283932 width=89)
Workers Planned: 7
-> Parallel Seq Scan on main_parcels_cb_intersects (cost=20505897.97..3330354543124.20 rows=5754847 width=89)
Filter: (NOT (SubPlan 1))
SubPlan 1
-> Materialize (cost=20505897.97..21069329.24 rows=6107669 width=4)
-> Unique (cost=20505897.97..21014931.89 rows=6107669 width=4)
-> Sort (cost=20505897.97..20760414.93 rows=101806784 width=4)
Sort Key: ((main_bldgs_cb_intersects.parcel_id)::integer)
-> Seq Scan on main_bldgs_cb_intersects (cost=0.00..5334454.80 rows=101806784 width=4)
但這不會告訴我確切的瓶頸發生在哪里，所以我試圖運行：
EXPLAIN ANALYZE
SELECT * FROM pop_allocation_sql.main_parcels_cb_intersects
WHERE parcel_id NOT IN (SELECT DISTINCT parcel_id::int
FROM pop_allocation_sql.main_bldgs_cb_intersects)
我讓它運行了一個多小時，沒有任何回報。我檢查了 PG ADMIN 并注意到等待事件說 Lock: transactionid 并給出了 119698 的阻塞 PID（我不確定這意味著什么）。為什么我的查詢無法完成？
uj5u.com熱心網友回復：
行程 ID 為 119698 的會話有一個打開的事務，該事務持有ACCESS EXCLUSIVE對查詢中的一個表的鎖。如有必要，結束該交易
SELECT pg_cancel_backend(119698);
如果您希望查詢性能更好，請將其重寫為
SELECT *
FROM pop_allocation_sql.main_parcels_cb_intersects AS p
WHERE NOT EXISTS (
SELECT FROM pop_allocation_sql.main_bldgs_cb_intersects AS pb
WHERE p.parcel_id = pb.parcel_id::integer
);
在DISTINCT完全沒有必要。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/388198.html