PostgreSQL10.1手冊_部分II.SQL語言_第15章並行查詢_15.4.並行安全性

李博bluemind發表於2018-10-02
SQL並行

15.4. 並行安全性

15.4.1. 為函式和聚合加並行標籤

規劃器把查詢中涉及的操作分類成並行安全、並行受限 或者並行不安全。並行安全的操作不會與並行查詢的使用產生衝突。 並行受限的操作不能在並行工作者中執行，但是能夠在並行查詢的領導者中執行。 因此，並行受限的操作不能出現在Gather或Gather Merge節點之下， 但是能夠出現在包含有這樣節點的計劃的其他位置。並行不安全的操作不能在並行查詢中執行，甚至不能在領導者中執行。當一個查詢包含任何並行不安全操作時，並行查詢對這個查詢是完全被禁用的。

下面的操作總是並行受限的。

  • 公共表表示式（CTE）的掃描。

  • 臨時表的掃描。

  • 外部表的掃描，除非外部資料包裝器有一個IsForeignScanParallelSafe API。

  • 對InitPlan或者相關的SubPlan的訪問。

15.4.1. 為函式和聚合加並行標籤

規劃器無法自動判定一個使用者定義的函式或者聚合是並行安全、並行受限還是並行不安全，因為這需要預測函式可能執行的每一個操作。一般而言，這就相當於一個停機問題，因此是不可能的。甚至對於可以做到判定的簡單函式我們也不會嘗試，因為那會非常昂貴而且容易出錯。相反，除非是被標記出來，所有使用者定義的函式都被認為是並行不安全的。在使用CREATE FUNCTION或者ALTER FUNCTION時，可以通過指定PARALLEL SAFE、PARALLEL RESTRICTED或者PARALLEL UNSAFE來設定標記 。在使用CREATE AGGREGATE時，PARALLEL選項可以被指定為SAFE、RESTRICTED或者 UNSAFE。

如果函式和聚合會寫資料庫、訪問序列、改變事務狀態（即便是臨時改變，例如建立一個EXCEPTION塊來捕捉錯誤的 PL/pgSQL）或者對設定做持久化的更改，它們一定要被標記為PARALLEL UNSAFE。類似地，如果函式會訪問臨時表、客戶端連線狀態、遊標、預備語句或者系統無法在工作者之間同步的後端本地狀態，它們必須被標記為PARALLEL RESTRICTED。例如，setseed和 random由於後一種原因而是並行受限的。

一般而言，如果一個函式是受限或者不安全的卻被標記為安全，或者它實際是不安全的卻被標記為受限，把它用在並行查詢中時可能會丟擲錯誤或者產生錯誤的回答。如果 C 語言函式被錯誤標記，理論上它會展現出完全不明確的行為，因為系統中無法保護自身不受任意 C 程式碼的影響。但是，在最有可能的情況下，結果不會比其他任何函式更糟糕。如果有疑慮，最好還是標記函式為UNSAFE。

如果在並行工作者中執行的函式要求領導者沒有持有的鎖，例如讀該查詢中沒有引用的表，那麼工作者退出時會釋放那些鎖（而不是在事務結束時釋放）。如果你寫了一個這樣做的函式並且這種不同的行為對你很重要，把這類函式標記為PARALLEL RESTRICTED以確保它們只在領導者中執行。

注意查詢規劃器不會為了獲取一個更好的計劃而考慮延遲計算並行受限的函式或者聚合。 所以，如果一個被應用到特定表的WHERE子句是並行受限的， 查詢規劃器就不會考慮在計劃的並行部分中執行對該表的掃描。 在一些情況中，可以（甚至效率更高）把對錶的掃描包括在查詢的並行部分並且延遲對WHERE子句的計算，這樣它會出現在Gather節點之上。不過，規劃器不會這樣做。

本文轉自PostgreSQL中文社群，原文連結：15.4. 並行安全性


相關文章