2026-06-17 — pg_kpart 強制分區鍵過濾、powa-archivist 5.1.2 模組獨立保留期、ClickHouse 開源十週年 (3 articles)

pg_kpart 1.0：強制分區鍵過濾的 PostgreSQL Planner Hook 擴充套件

PostgreSQL Global Development Group · 2026-06-16

2026 年 6 月 16 日，HexaCluster Corp 發佈 pg_kpart 1.0，這是一款以 PostgreSQL 授權條款釋出的擴充套件，專門用於在資料庫層面拒絕未使用分區鍵的全分區掃描查詢。該擴充套件以 planner hook 機制介入查詢規劃階段，將「務必在 WHERE 條件中帶入分區鍵」的工程慣例轉化為可執行的資料庫保證，適用於 Linux 平台上所有受支援的 PostgreSQL 版本。

背景

水平分區（partitioned table）是 PostgreSQL 管理超大型資料集的核心手段。Partition pruning（分區剪枝）機制的前提是查詢的 WHERE 條件必須涉及分區鍵欄位；一旦開發人員遺漏此條件，PostgreSQL 會對每個子分區都發起 sequential scan，在包含數百乃至數千個分區的生產系統中，瞬間觸發 I/O 風暴。傳統的解法是透過 code review 或 ORM 層的防護，但這些方法均無法在資料庫執行時強制執行。pg_kpart 的誕生正是為了填補這個缺口。

維護者 Gilles Darold（HexaCluster Corp）採用 PostgreSQL 的 planner hook 介面：在標準規劃器完成後，擴充套件掃描查詢計畫樹，尋找指向分區資料表的 Append 或 MergeAppend 節點，並判斷該節點的 part_prune_info 欄位是否存在可用的分區鍵謂詞。若規劃器確認查詢無法剪除任何子分區，pg_kpart 即直接拒絕該查詢的執行。

核心改動

pg_kpart 透過六個 GUC（Grand Unified Configuration）參數提供細粒度控制：

• pg_kpart.enabled（預設 on）：全域開關，可在 session 層級臨時關閉。
• pg_kpart.message_level（預設 error）：可調整為 warning 或 notice，以支援 audit 模式部署。
• pg_kpart.min_partitions（預設 2）：只針對子分區數超過此閾值的資料表啟用檢查。
• pg_kpart.check_superuser（預設 off）：決定是否對 superuser 角色也套用限制。
• pg_kpart.blacklisted：指定必須強制檢查的資料表清單，優先級高於白名單。
• pg_kpart.whitelisted：指定豁免檢查的資料表清單。

執行時若查詢被拒絕，PostgreSQL 會回傳自訂 SQLSTATE 代碼 FS001，讓應用程式能在 catch 區塊中明確識別此類錯誤並加以處理，而非與一般的 syntax error 或 permission error 混淆。強制範圍涵蓋 SELECT、UPDATE、DELETE 及 EXPLAIN 語句；Prepared statement 僅在重新規劃時才會重新檢查。

以下範例展示一個正確使用分區鍵的查詢與一個被拒絕的查詢：

-- 允許：WHERE 條件含分區鍵，規劃器可剪枝
SELECT * FROM logs WHERE logdate = '2026-06-16';

-- 拒絕：謂詞涵蓋所有分區，part_prune_info 為空
SELECT * FROM logs WHERE logdate > '1900-01-01';
-- ERROR:  FS001: full partition scan is not allowed on table "logs"

影響範圍

部署前建議先以 audit 模式（pg_kpart.message_level = 'warning'）上線，讓既有查詢的違規行為被記錄至 PostgreSQL log，而不立即中斷服務。待開發團隊修正相關查詢後，再將 message_level 切換回 error。此擴充套件需要加入 shared_preload_libraries 才能生效；由於 session 層級可透過 SET pg_kpart.enabled = off 繞過，它定位為防護「意外的」全掃描，而非安全邊界控制。

對於採用 pg_partman 等工具管理月份或日期範圍分區、且分區數量持續成長的場景，pg_kpart 可有效將規範層的約定下沉至資料庫執行層，避免因 ORM 升級或程式碼改動而引入的迴歸風險。原始碼與文件均已公開於 GitHub，採 PostgreSQL License 授權。

原始來源：pg_kpart README (GitHub)、pg_kpart Releases (GitHub)

powa-archivist 5.1.2 發佈：新增每模組獨立保留策略支援

PostgreSQL Global Development Group · 2026-06-16

2026 年 6 月 16 日，PoWA 團隊正式釋出 powa-archivist 5.1.2，這是 PostgreSQL Workload Analyzer（PoWA）專案的核心擴充套件。此版本帶入一項由 Marc Cousin 貢獻的新功能：每模組獨立保留期設定（per-module retention），讓 DBA 得以為不同資料來源配置差異化的資料保留策略，而無需套用全域統一設定。powa-archivist 相容所有目前受官方支援的 PostgreSQL 版本。

背景

PoWA 是一套以 PostgreSQL 擴充套件為基礎的效能監控框架，其設計圍繞著「archivist」（歸檔器）與「collector」（採集器）兩個角色運作。powa-archivist 作為 archivist 端的核心組件，負責在 PostgreSQL 執行個體內部聚合並保存來自 pg_stat_statements、pg_stat_bgwriter、pg_stat_wal、pg_stat_io 等多個統計視圖的歷史資料，並支援第三方擴充套件（如 pg_qualstats、pg_wait_sampling）作為外掛模組整合。

在 5.1.2 之前，保留期只能設定全域單一值；對於採集頻率高、資料量大的模組（例如 pg_stat_statements）與僅在事件發生時才有意義的模組（例如 pg_track_settings），一刀切的保留策略會造成儲存空間的浪費，或讓關鍵診斷資料過早遭到清除。5.1.x 系列自 2025 年 11 月起持續針對此問題與 PostgreSQL 18 相容性進行改善。

核心改動

5.1.2 的主要變動集中在一項新功能：

• per-module retention（Marc Cousin 貢獻）：在模組設定資料表中新增每個模組的保留期欄位，允許各模組套用不同的資料保留週期，不再受限於全域參數 powa.retention。

回顧整個 5.1.x 系列，以下表格整理了各版本的主要改動：

5.1.1 中修正的 TOAST 表大小重複計算是一個影響資料庫大小統計準確性的已知錯誤：當 powa-archivist 在採集資料表大小時，TOAST 分頁的大小會被計入主要資料表與 TOAST 資料表各一次，導致監控圖表中的儲存空間數字偏高。此問題已在 5.1.1 中徹底修正。

影響範圍

per-module retention 功能對於同時監控多個 PostgreSQL 執行個體、且各執行個體負載特性差異顯著的環境最具實際意義。以監控一個高頻 OLTP 系統與一個低頻 OLAP 系統並存的場景為例，DBA 可對 OLTP 側的 pg_stat_statements 模組設定較短的保留期（如 7 天），同時對 OLAP 側的 pg_wait_sampling 模組保留 30 天的歷史資料，而不影響彼此。

若目前運行的是 powa-archivist 5.0.x 或更早版本，升級前須留意 pg_stat_io 相關的 schema 調整（5.1.1 引入），以及 PostgreSQL 18 下的相容性修正。完整的升級說明與 CHANGELOG 可於 GitHub Releases 頁面取得。powa-archivist 完整文件持續維護於 powa.readthedocs.io。

原始來源：powa-archivist Releases (GitHub)、PoWA 官方文件

ClickHouse 開源十週年：從 Yandex 內部工具到全球分析資料庫的技術演進

ClickHouse, Inc. · 2026-06-15

2016 年 6 月 15 日，ClickHouse 以 Apache 2.0 授權正式開源；十年後的今天，這套列式分析資料庫已累積超過 2,600 名貢獻者、約 48,000 顆 GitHub star 與逾 2.39 億次 commit，成為全球部署最廣泛的 OLAP 資料庫之一。ClickHouse, Inc. 於 2026 年 6 月 15 日發表回顧文章，以量化數據與技術細節梳理這十年間的架構演進。

原本的問題

ClickHouse 起源於 Yandex 內部，最初是為了滿足大規模 web 分析（Yandex.Metrica）的即時查詢需求而開發。在開源之初，JOIN 效能是公認的弱點：ClickHouse 的設計哲學傾向於 denormalization 與寬表，複雜的多表關聯查詢往往需要繞道 materialized view 或 ETL 預處理。此外，原生 JSON 支援缺位、全文搜索需仰賴外部索引、向量搜索場景則完全無解，使其在新興 AI 與多模態分析工作負載面前顯得力不從心。

社群規模持續成長帶來的另一面挑戰，是跨版本效能一致性的維護難度。ClickHouse 每年釋出多達十餘個版本，在保持向後相容性的同時推進底層優化，需要嚴謹的基準測試體系支撐。這也促使官方建立了 ClickBench、JSONBench、TPC-H、CostBench、PostgresBench 等一系列開放可重現的基準測試套件。

採用的方法

十年間，ClickHouse 在四個核心技術方向上持續投入。第一是 JOIN 優化：透過相關子查詢解關聯（correlated subquery decorrelation）、惰性欄位複製（lazy column replication）以及執行期過濾器（runtime filters），TPC-H SF100 工作負載的 JOIN 效能在 v22.4 至 v26.4 之間提升了 26 倍。其中 runtime filters 的效果最為顯著——某個查詢的記憶體消耗從 1.24 GiB 降至 185 MiB。

第二個方向是 SQL 能力擴充。v25.7 引入了真正的 UPDATE/DELETE 操作，相較於傳統的 mutation 機制，批次更新速度提升達 1,700 倍。v25.3 正式推出 production-ready 的原生 JSON 型別，在與 MongoDB 的對比測試中，JSON 聚合查詢速度快出 2,500 倍，同時儲存空間減少 40%。v26.2 則帶入基於倒排索引（inverted index）的原生全文搜索，冷查詢速度提升 7 至 10 倍。

以下為 v25.x 至 v26.x 間重要功能的效能提升彙整：

第三個方向是向量搜索與 AI 整合。2025 年 10 月引入的 QBit 向量索引，使向量相似度搜索速度提升 2 倍、吞吐量提升 4.3 倍，讓 ClickHouse 在嵌入向量的儲存與檢索場景中具備與專用向量資料庫競爭的能力。第四個方向是並行執行架構：parallel replicas（beta）功能使對 1,000 億行的原始 GROUP BY 查詢在 414 毫秒內完成，展示了分散式掃描的上限潛力。

實際效果

僅在 2025 年一年內，ClickHouse 便釋出 12 個版本，交付 277 項新功能、319 項效能優化與 1,051 個錯誤修正。社群層面，Amos Bird 對 projections indexing 的貢獻、Michael Jarrett 對 minmax 索引的改進，以及 Konstantin Vedernikov 的 CoalescingMergeTree 引擎，均已合併進主線，成為商業版本的基礎元件。

ClickHouse 於 2026 年的 Open House 活動中啟動「Community Champions Program」，以正式機制認可社群貢獻者。所有官方基準測試均開放原始碼且可在本地重現，這在商業分析資料庫領域仍屬少見，反映出 ClickHouse 對效能透明度的一貫堅持。十年後，ClickHouse 已從單一用途的 web 分析工具，演變為同時支援 OLAP、JSON 分析、全文搜索與向量搜索的多模態分析平台。

原始來源：ClickHouse 官方部落格