共計 1159 個字符，預計需要花費 3 分鐘才能閱讀完成。

PostgreSQL 表分區不同實現的示例分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

pg_pathman 更新提供了更改查詢和刪除查詢的支持. 由于使用了 PostgreSQL 查詢計劃掛鉤，更新和刪除規劃在對單個分區查詢時, 速度會有改善 其他方式的查詢，依舊使用緩慢的繼承查詢規劃 當然,UPDATE,DELETE 操作只涉及一個一個分區的情況似乎是最常見, 最需要優化的。

此外，分享一些基準測試。這一基準測試是一年的記賬, 按天來做表分區，總計約 1 百萬 (1M) 條數據 當然，這只是個測試示列，因為在實際中由于數據量太小, 沒有人會分成這么多分區

但它仍然很高興見到分區開銷。下列操作的性能進行比較:

選擇單行 (使用時間戳) SELECT one;

選擇某一天的全部數據(查詢單個分區的全部數據) SELECT one_partation

隨機插入單行 (使用隨機時間戳) INSERT

隨機更新單行 (使用隨機時間戳篩選) UPDATE

以下的分區方法進行了比較︰

單表，沒有使用分區 pg_partman 擴展 pg_pathman 擴展

在 2xIntel Xeon CPU X5675 @ 3.07GHz, 24 GB 內存的服務器上, 數據庫參數配置 fsync=off 使用 10 個線程可以得到如下的結果。

我可以得到以下結論

pg_pathman 顯著優于 pg_partman, 主要是由于 pg_pathman 使用查詢計劃鉤子, 而 pg_partman 使用內置的繼承機制.

當選擇查詢或更新單個行時，pg_pathman 和普通表幾乎是一樣快, 插入單個行的差異是稍大一點，因為觸發器用來的

在選擇整個分區查詢時,pg_partman 和 pg_pathman 時選擇整個分區之間的區別不是那樣數十倍(在查詢單行時)。因為這時, 查詢規劃時間只占整個語句執行時間的一小部分。

隨機 INSERT 時,pg_pathman 的執行速度仍然遠遠超過與 pg_partman, 是由于其他兩者在在父關系上使用了觸發器, 但是,pg_pathman 使用了快速的 C 函數來實現。

選擇整個分區表分區由 pg_pathman 的時候是略高于從平原表中選擇相同的行。這是因為在掃描整個表分區時，使用了順序掃描，而索引掃描用于選擇表的一部分。當數據量很大, 緩存不足以存下時, 這種差異預計會更大。

用于基準測試的 SQL 腳本，請參閱此依據。

create_*.sql 創建日記帳表使用分區的各種方法。pg_bench 的腳本: select_one.sql、select_day.sql、insert.sql 和 update.sql .

看完上述內容，你們掌握 PostgreSQL 表分區不同實現的示例分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！