Postgres-XC 和 MPP
我目前正在考慮使用 Postgres-XC 或 Postgres-XL 為大約 20 TB 或更多的數據創建一個長期數據儲存。
我在 Postgres-XL 網站上閱讀了 Postgres-XC 還不是 MPP 架構的資訊。但是，我可以看到它已經有一個充當主節點的“協調器”和一堆不共享數據的數據節點（無共享）。
是什麼讓 Postgres-XC 不是 MPP？
我是這兩個項目的原始開發人員之一。
他們都有一個 Coordinator 和 Datanodes，這是真的。協調員也計劃並指導兩者的執行。
也許幾個例子會有所幫助。
假設您有三個表
t1，t2和r1。t1有a1和a2,t2有b1和b2.t1分佈（分片）在 上a1，並且t2分佈在 上b1。r1有列c1並且c2被複製，每一行都有一個精確的副本對於像這樣的簡單查詢
SELECT * FROM t1，它將在 Postgres-XC 和 Postgres-XL 中並行化。另一個例子：
SELECT * FROM t1 INNER JOIN r1 ON t1.a1 = r1.c1也將在兩者中並行化，連接被“下推”到數據節點。我們可以這樣做，因為
r1在每個節點上都進行了複製。這種類型的查詢很好，哪裡t1是一個大的事實表並且r1是一個維度表。讓我們看一個不同的案例：
SELECT * FROM t1 INNER JOIN t2 ON t1.a1 = t2.b2在這裡，我們加入了 的分佈列
t1，但沒有加入 的分佈列b2。在一個 4 節點集群中，node1 上的行t1可能需要與t2node1、node2、node3 和 node4 上的行連接。Postgres-XC 通過將所有符合連接條件的數據從每個表傳送到協調器並在那裡連接來處理這個問題。在範例中，我們沒有包含任何
WHERE子句限定符。因此，它會將 t1 和 t2 的全部內容從 node1、node2、node3 和 node4 傳送到 Coordinator，然後加入那裡。不會有連接並行性，而且您還需要將所有數據傳送到一個地方的成本。所以在這種情況下，Postgres-XC 實際上會比本地 PostgreSQL 慢，如果表很大，則要慢得多。Postgres-XL 會以不同的方式處理這個問題。記住連接條件是
t1.a1 = t2.b2。它會認出b2是 equijoineda1，也就是分佈列t1。也就是說，如果我們有這個b2值，我們就可以準確地知道它需要加入的數據t1駐留在哪個節點上（因為我們可以對這個值應用散列分佈函式）。由於數據是在每個節點上產生的t2，它將被恰好需要它的一個數據節點消費t1，並且直接這樣做而不通過協調器。數據節點同時讀取
t1並生成t2用於連接的行，t1數據t2節點直接使用數據節點，該數據節點需要特定行的數據。與 Postgres-XC 相比，這種直接的數據節點到數據節點通信允許對更複雜的查詢進行更多的並行化。
我希望這有助於回答你的問題。
Postgres-XL 還具有其他性能改進。序列被更優化地處理。