PostgreSQL 非對稱連線的演進：從分割槽連線到更高效能

– 8 分鐘閱讀

在資料函式庫最佳化的領域中，連線（Join）操作一直是最具挑戰性的環節之一。PostgreSQL 最近引入的非對稱連線（Asymmetric Join，簡稱 AJ）最佳化技術，為處理分割槽資料表（Partitioned Relation，PR）與非分割槽資料表（Non-partitioned Relation，NR）之間的連線操作帶來了嶄新的思路。這項技術可視為傳統分割槽連線（Partitionwise Join）的進階演進版本。

非對稱連線的核心概念

非對稱連線的核心思想在於將每個分割槽獨立地與非分割槽資料表進行連線，再透過 APPEND 操作合併結果。這種方法實際上可以將複雜的連線操作轉換為更簡單與更有效率的形式。

查詢轉換範例

假設我們有一個標準的連線查詢：

SELECT * FROM A JOIN partitioned B ON A.x = B.x;

使用非對稱連線最佳化後，這個查詢會被轉換為：

(SELECT * FROM A JOIN B_1 ON A.x = B_1.x)
UNION ALL
(SELECT * FROM A JOIN B_2 ON A.x = B_2.x);

在 PostgreSQL 的程式碼實作中，這項最佳化主要體現在 ‘relnode.c’ 與 ‘joinrels.c’ 這兩個核心檔案中。

技術優勢分析

效能提升與資源最佳化

  1. 平行處理效率提升： 透過改善 Parallel Append 的運作機制，讓平行處理更加有效率。

  2. 靈活的連線策略： 系統能夠為每個分割槽選擇最佳的連線策略，而不是被迫使用統一的方式。

  3. 記憶體使用最佳化： 由於每個 HashJoin 的雜湊表大小較小，可以顯著降低記憶體使用量，同時避免資料傾斜問題。

查詢最佳化增強

  1. 條件下推最佳化： 能夠將分割槽條件直接下推到內部查詢，提升資料掃描的效率。

  2. 分割槽剪枝改善： 提供更多機會找出可以剪枝的分割槽，減少不必要的資料處理。

  3. 外部資料處理： 為外部資料包裝器（Foreign Data Wrapper）提供更好的支援，特別是在處理外部資料表時。

實作限制與考量

技術限制

  1. 內部連線限制： 作為 AppendJoin 的內部資料表必須是單一資料表或不包含上層分割槽資料表的查詢子樹。

  2. 參考限制： 外部 AppendJoin 不能參照內部連線。

  3. 計劃搜尋空間： 隨著查詢複雜度增加，計劃搜尋空間會顯著擴大。

實作細節

在實作層面，非對稱連線最佳化主要透過 build_joinrel_partition_info 函式來處理。這個函式負責初始化 RelOptInfo 結構中的分割槽相關屬性，包括 part_scheme 和 part_exprs。當系統無法使用傳統的分割槽連線時，就會考慮採用非對稱連線策略。

在玄貓多年的資料函式庫化經驗中，這種最佳化策略特別適合處理大型資料倉儲中的複雜查詢。當面對不同規模的分割槽資料表進行連線操作時，非對稱連線能夠提供更好的效能表現。透過仔細權衡查詢計劃的選擇，可以在特定場景下獲得顯著的效能提升。

非對稱連線的引入不僅展現了 PostgreSQL 在查詢最佳化方面的持續創新，也為處理複雜資料關係提供了更多可能性。隨著資料量持續增長，這類別最佳化技術將在未來扮演更重要的角色。作為資料函式庫師，我們需要深入理解這些最佳化機制，才能在實際應用中做出更明智的技術選擇。

在多年深入研究PostgreSQL查詢最佳化器的過程中，玄貓發現分割資料表（Partitioned Table）的連線最佳化是一個極具挑戰性的課題。今天我要分享一個關於非對稱分割連線（Asymmetric Partitionwise Join，簡稱AJ）的深度技術分析。

非對稱連線的特殊性

非對稱連線最顯著的特點在於build_joinrel_partition_info的處理邏輯。從我的實務經驗來看，這種連線方式與一般的分割表連線（Partitionwise Join，簡稱PWJ）有著根本的不同。讓我進一步解釋其中的細節：

連線策略的選擇邏輯

假設我們需要連線兩個採用相同分割方案的資料表P1、P2以及一個普通資料表T，連線策略的選擇會依據以下邏輯進行：

  1. 當outer = (P1, P2), inner = (T)時，PWJ無法建立，系統會初始化AJ
  2. 當external = (P1, T), inner = (P2)時，PWJ選項會被略過
  3. 若調整組合順序，最佳化器會先嘗試建立(P1, T) JOIN (P2)，再初始化PWJ

實際測試案例分析

讓我們看一個具體的測試範例：

-- PWJ優先的查詢
EXPLAIN (COSTS OFF)
SELECT * from prt1 d1, unnest(array[3,4]) n, prt2 d2
WHERE d1.a = n AND d2.b = d1.a;

-- AJ優先的查詢
EXPLAIN (COSTS OFF)
SELECT * from prt1 d1, prt2 d2, unnest(array[3,4]) n
WHERE d1.a = n AND d2.b = d1.a;

從我的觀察來看，無論最佳化器如何組合inner和outer來建構joinrel，part_scheme都會指向相同的位置，而part_exprs則會依據元素的排列順序進行相應調整。

最佳化器決策機制的深入剖析

在研究最佳化器的決策過程時，玄貓發現了一個關鍵問題：對於同一個joinrel，不同的inner和outer組合是否可能導致不同的AJ執行決策？為瞭解答這個問題，我們在build_join_rel()中加入了檢查機制。

關於AJ的實作考量

在實作AJ時，我們面臨兩個主要選項：

  1. 儲存已允許的inner和outer組合
  2. 在try_asymmetric_partitionwise_join中重新驗證AJ條件

根據效能考量，玄貓建議採用第一種方案。原因在於：PWJ的consider_partitionwise_join標記是從最底層的分割資料表開始逐層建立，形成一個具有繼承性質的決策樹。相比之下，如果在AJ中採用相同策略，我們將需要額外檢查各種掃描方式（如TABLESAMPLE、Function Scan等）。

效能最佳化建議

根據多年的效能調校經驗，玄貓建議考慮引入safe_for_asymmetric_join標記。這樣只需要檢查當前的RelOptInfo和下層節點的標記，就能達到接近PWJ的實作效率。

try_asymmetric_partitionwise_join的實作細節

在populate_joinrel_with_paths中，try_asymmetric_partitionwise_join會在try_partitionwise_join之後被呼叫。考慮到呼叫者可能不會檢查輸入的排序，我們需要在函式內部處理這個問題。

玄貓特別注意到，我們可以透過調整連線類別來實作inner和outer的交換。例如，將LEFT OUTER JOIN轉換為RIGHT OUTER JOIN。這種靈活的處理方式能夠提供更好的最佳化空間。

經過長期的實務經驗，玄貓發現這種最佳化方式不僅能提升查詢效能，還能降低系統資源的使用。在處理大規模分割資料表時，這種最佳化策略的效果特別明顯。

這些年來，在為各種大型系統進行效能最佳化時，我發現合理的連線策略選擇對查詢效能有著決定性的影響。正確實作非對稱連線不僅能提升查詢效能，還能為未來的擴充套件預留充足的最佳化空間。

在多年參與資料函式庫化專案的經驗中，玄貓發現分割槽化查詢（Partitioned Query）的最佳化是提升大規模資料函式庫的關鍵。今天讓我們探討 PostgreSQL 中分割槽化查詢最佳化的核心實作細節。

分割槽化查詢最佳化的核心機制

在實作分割槽化查詢最佳化時，第一步是建立示範查詢（Demo Query）來驗證程式碼片段所帶來的最佳化限制。當我們在建立子連線關聯（Child Joinrel）時，系統會在內部層級驗證非對稱連線（Asymmetric Join）的正確性。

RelOptInfo 初始化流程

在處理 RelOptInfo 的分割槽相關欄位時，系統會初始化以下關鍵元素：

  • boundinfo：分割槽邊界資訊
  • nparts：分割槽數量
  • part_rels：分割槽關聯資訊

若這些欄位已經完成初始化，系統會執行分割槽結構（Partition Schema）的一致性檢查：

Assert(joinrel->nparts == prel->nparts && joinrel->part_rels != NULL);

分割槽連線路徑的生成

在建立分割槽連線路徑時，玄貓注意到一個關鍵步驟：系統需要替換分割槽表格的 relid 參照（Reference）。這個過程涉及將分割槽表格的 relid 替換為對應分割槽的 relid。完成替換後，系統會呼叫 populate_joinrel_with_paths 函式，並將路徑加入子連線關聯的 pathlist。

引數化處理機制

引數化巢狀迴圈（Parameterised NestLoop）是與非對稱連線密切相關的重要功能。在實務經驗中，玄貓發現引數化表示式可能會參照到位於引數化巢狀迴圈外部的非對稱連線。

路徑複製與引數化

為了確保引數化處理的正確性，我們引入了 is_asymmetric_join 函式。這個函式主要用於：

  • 識別非對稱連線的路徑
  • 在需要時觸發路徑的 relid 替換操作

當系統偵測到非對稱連線時（即一個輸入為分割槽，另一個為基礎關聯或連線關聯），就會執行路徑複製操作。這種保守的處理方式雖然可能會消耗較多記憶體，但能確保查詢處理的正確性。

技術挑戰與待解決問題

在實作過程中，玄貓發現仍有幾個重要的技術挑戰需要解決：

連線條件的完整性檢查

當連線條件包含不穩定函式（Volatile Function）時，我們需要更嚴謹的檢查機制。這涉及到查詢最佳化器如何評估這些函式的影響，以及如何在保持查詢正確性的同時實作最佳效能。

核心整合問題

目前系統還需要解決與 PostgreSQL 核心的原生整合問題，特別是 root->simple_*** 陣列的擴充套件機制。這個問題直接影響到最佳化器的功能完整性。

分割槽方案的一致性

在處理多重非對稱連線時，不同的簡單條件組合是否會導致不同的分割槽方案？這個問題涉及到：

  • 分割槽選擇的影響
  • part_rels[i] 的差異處理
  • 查詢計畫的建立策略

在多年的資料函式庫化工作中，玄貓深刻體會到這些技術細節對系統效能的重要影響。持續改進這些機制不僅能提升查詢效能，更能為未來的功能擴充套件奠定堅實基礎。透過深入理解這些核心機制，我們能更好地最佳化大規模資料函式庫的效能表現。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。