PostgreSQL 9.6 水準分庫，還差一點點啦

postgresql 持續在基于fdw的sharding技術上深耕，9.6開始，在符合條件的前提下，支援join和sort下推到資料節點執行。

下面是一個測試

建立幾個shard庫

建立master庫

在master庫建立foreign server和user mapping

在shard庫建立分片表

在master庫建立foreign 表，并設定限制

檢視

結果

在master庫建立父表

在master庫建立foreign表和父表的繼承關系

測試join的下推

目前sort下推需要關閉優化器enable_sort開關才會下推，也是值得改進的地方

還需要改進的地方

這樣的查詢優化器能優化什麼？

如果要更純粹的sharding，父表不應該參與計算，隻是一個别名而已。是以join 可以根據前提條件下推。

tab.id=tbl.id and mod(tbl.id,4)=1 可以推演出 and mod(tab.id,4)=1 。 是以tab表隻需要掃描tab1。

修改源碼，允許删除繼承的限制

vi src/backend/commands/tablecmds.c

重新編譯，重新開機

添加主表的限制，删除子表的限制，造成主表不被通路的假象。

我的目标是這樣能做到下推join，但實際上沒有下推，這個是非常痛苦的。

一個真正的分庫中間件應該解決這樣的問題。

這才是我要的結果

通常應用會以父表作為常用的表，而不是直接通路子表，但是可以要求使用者帶上分區限制的條件，進而滿足下推的排他性。

pg應該允許父表和子表有不一樣的限制，進而可以利用排他限制把父表的通路過濾掉。

父表通路過濾掉之後，子表的join應該可以下推使用。

複制表的實作和下推？

在postgresql的shard完美之前，使用者應該盡量避免join。