2026-06-13 — PostgreSQL 19 Beta 1 多項效能突破、純 Clojure 欄式分析庫 Flatiron、PG19 原生時態資料表

PostgreSQL 19 Beta 1 正式發布：非同步 I/O、平行化 Vacuum 與 SQL/PGQ 圖查詢一次到位

PostgreSQL Global Development Group · 2026-06-04

PostgreSQL 全球開發群組於 2026 年 6 月 4 日發布 PostgreSQL 19 的第一個 Beta 版本，涵蓋效能、可觀測性、安全與 SQL 標準相容性等四大方向的重大改動。預計正式版將於 2026 年 9 至 10 月推出，目前開放社群測試以蒐集回饋。

核心改動

非同步 I/O 自動擴縮是本次最受矚目的底層改動。當 io_method=worker 時，PostgreSQL 19 可依據工作負載動態調整 I/O worker 數量，透過 io_min_workers 與 io_max_workers 設定上下限，減少 I/O 瓶頸對查詢延遲的影響。

Vacuum 與維護作業也獲得全面強化。平行 autovacuum worker 可透過 autovacuum_max_parallel_workers 設定，加速大型資料表的回收效率；新的 autovacuum 評分機制讓系統更精準地排定需要優先處理的資料表。此外，全新的 REPACK ... CONCURRENTLY 指令允許在不鎖表的情況下重建資料表結構。

查詢執行層面同樣有顯著進步。以下是 PostgreSQL 19 在查詢最佳化方面的主要改動：

• 含外鍵約束的 INSERT 效能提升約 2 倍
• Anti-join 最佳化，減少不必要的巢狀迴圈
• Incremental sort 適用範圍擴大
• enable_eager_aggregate 控制的 Eager Aggregation，提前彙總減少後續資料量
• 平行循序掃描（Parallel Sequential Scan）正式支援

SQL 語法與標準相容性

PostgreSQL 19 加入了 SQL/PGQ（Property Graph Queries） 支援，讓使用者可用 SQL 標準語法直接對圖結構資料進行遍歷查詢，不需要另外安裝圖資料庫。這是關聯式資料庫走向多模型（multi-model）的重要一步。

GROUP BY ALL 是另一個實用的便利語法，自動將所有非彙總、非視窗函式的輸出欄位加入分組鍵，減少手動列舉欄位的負擔。Upsert 操作也有更新：

INSERT INTO orders ...
ON CONFLICT DO SELECT ...
RETURNING order_id, status;

衝突發生時，RETURNING 子句現在也能取回被衝突列的欄位值，簡化應用程式層的錯誤處理邏輯。

複本讀取一致性透過新的 WAIT FOR LSN 指令得到原生支援。在讀寫分離架構中，應用程式可等待特定 WAL 位置被 Standby 重播完畢，再對該 Standby 發出讀取查詢，確保「寫後即讀」的一致性，不再需要自行實作輪詢邏輯。

可觀測性與安全

監控方面新增兩個系統檢視：pg_stat_lock 提供各鎖類型的統計，pg_stat_recovery 則詳細揭露備援恢復進度。EXPLAIN ANALYZE 現在支援 IO 選項，可直接顯示非同步 I/O 的統計數據，讓效能調校更有依據。

安全方面，PostgreSQL 19 透過新增 pg_hosts.conf 支援 TLS Server Name Indication（SNI），讓單一 PostgreSQL 實例可依客戶端請求的主機名稱呈現不同 TLS 憑證。另外，md5 認證方式正式進入棄用流程：成功登入後將顯示警告訊息，督促管理員改用更安全的認證機制。

影響範圍

本次 Beta 也包含幾項需要注意的破壞性變更。JIT 即時編譯預設關閉，原因是在某些工作負載下 JIT 的編譯開銷超過執行收益；default_toast_compression 預設值由 pglz 改為 lz4，壓縮與解壓縮效能均有提升；RADIUS 認證支援已移除。

邏輯複寫架構也有重要鬆綁：啟用邏輯複寫不再需要將 wal_level 設為 logical，維持 replica 等級即可按需啟用，降低線上升級的操作複雜度。資料 Checksum 也可在不重啟或重新初始化叢集的情況下線上啟用或停用。PostgreSQL 19 Beta 1 可從官方網站下載，開發群組呼籲使用者在非生產環境中測試並回報問題。

原始來源：PostgreSQL Global Development Group — PostgreSQL 19 Beta 1 Released

純 Clojure 打造的欄式分析資料庫：Flatiron 的設計哲學與效能邊界

GitHub (yogthos/flatiron) · 2026-06-13

Flatiron 是一個以純 Clojure 實作的欄式分析資料庫函式庫，不依賴任何 JNI 原生程式碼，僅需 core.async 作為外部相依。它提供類 SQL 的 DSL、視窗函式、樞紐分析，甚至內建圖演算法，目標是讓 Clojure 開發者無需離開 JVM 生態即可進行高效能資料分析。

核心改動

Flatiron 的儲存核心是每欄一個型別化的原始陣列（primitive array），避免 JVM 的裝箱（boxing）開銷。支援的型別包括：

• I64：long[]，有號 64 位元整數
• F64：double[]，64 位元浮點數
• Bool：byte[]，布林值
• Sym：Object[]，Clojure keyword
• Str：Object[]，字串

Morsel 執行引擎是效能的關鍵。它以 1024 列為一批次處理資料，每批次只做一次型別分派（type dispatch），隨後在緊密迴圈中對原始陣列直接操作，大幅降低 JVM 動態分派的成本。這個設計與 Apache Arrow 的 Record Batch 概念相近，但完全以 Clojure 的巨集系統在編譯期展開，不存在執行期的 DSL 解析。

查詢 DSL 的操作在巨集展開時直接轉換為函式呼叫，以下是一個分組彙總的範例：

(select table
  [:category (sum :revenue) (count :order_id)]
  (where (> :revenue 100)))

除了基本的 where、select、pivot，Flatiron 也支援視窗函式如 row-number、rank、dense-rank、lag、lead，以及單次掃描完成的 sum、avg、min、max 等彙總函式。

平行化與 I/O

Flatiron 提供 parallel-group-by，以基數分區（radix partition）依鍵值雜湊將資料切分後平行處理。排序採用 TimSort 作用在索引陣列上，不移動欄資料本身，避免大量記憶體複製。過濾操作使用選擇位元圖（selection bitmap），讓過濾與彙總可以管線化執行，不需要具體化中間結果資料表。

持久化格式採用「每欄一個檔案」的二進位佈局，並附帶元數據檔案。讀取時盡可能達到零複製（zero-copy）。CSV 支援從前 100 列自動推斷型別。內建圖演算法（BFS、DFS、Dijkstra、PageRank、連通元件）使用 CSR（Compressed Sparse Row）表示法，在單次掃描中建立正向與反向鄰接表，適合在同一份資料上同時做關聯式查詢與圖分析。

影響範圍

在 Apple M1 Max 上以 100 萬列測試，Flatiron 與以 SIMD 和自訂記憶體分配器實作的 C 版本（Rayforce）相比，效能差距如下：

與 C 的差距維持在一個數量級以內，對於純 JVM 實作而言已屬優異。Flatiron 的定位不是取代 DuckDB 或 ClickHouse 這類生產級系統，而是為 Clojure 生態提供一個可內嵌、易擴展、不需要跨語言橋接的分析能力。專案需要 Clojure 1.12.0、core.async 1.6.681 與 JDK 18 以上（使用 Math/unsignedMultiplyHigh），CI 環境測試 JDK 21 與 25。

原始來源：yogthos/flatiron — GitHub

PostgreSQL 19 原生時態資料表：WITHOUT OVERLAPS 與 FOR PORTION OF 如何終結手工時間範圍管理

pgEdge Blog · 2026-06-13

PostgreSQL 19 引入了符合 SQL 標準的應用程式時態資料表（application-time temporal tables），讓資料庫能夠原生回答「上週二這筆記錄長什麼樣子？」這類問題。pgEdge 工程師深入解析了 WITHOUT OVERLAPS 主鍵約束與 FOR PORTION OF 更新語法，說明它們如何取代過去依賴 GiST 索引的繁瑣做法。

原本的問題

在 PostgreSQL 18 及更早版本中，要防止同一個實體（如產品 ID）的有效時間範圍重疊，必須使用排除約束（exclusion constraint）：

-- 舊做法：需要 GiST 索引
EXCLUDE USING gist (
  product_id WITH =,
  valid_at WITH &&
);

GiST 排除約束難以理解、難以維護，且對開發者不友善。更大的問題是，當需要更新某個時間範圍的中段時，開發者必須手動將原始列拆分為三段（更新前、更新段、更新後），並自行管理邊界的精確對齊，極易出錯。

採用的方法

PostgreSQL 19 將時態感知能力直接嵌入主鍵定義：

CREATE TABLE products (
  product_id  INT,
  valid_at    DATERANGE,
  price       NUMERIC,
  PRIMARY KEY (product_id, valid_at WITHOUT OVERLAPS)
);

WITHOUT OVERLAPS 讓引擎在主鍵層級原生阻止時間範圍重疊，語意直觀、不需要額外索引類型知識。對時間範圍中段的更新與刪除則透過 FOR PORTION OF 子句完成：

-- 更新某段時間內的價格
UPDATE products
   FOR PORTION OF valid_at FROM '2025-03-01' TO '2025-09-01'
   SET price = 10.99
 WHERE product_id = 1;

-- 刪除某段時間的記錄
DELETE FROM products
   FOR PORTION OF valid_at FROM '2025-06-01' TO '2025-10-01'
 WHERE product_id = 2;

引擎會自動拆分受影響範圍外的剩餘列，開發者不需要手動處理邊界切割。時態外鍵也同時加入，允許在引用完整性中加入時間維度的比對：

FOREIGN KEY (product_id, PERIOD valid_at)
    REFERENCES products (product_id, PERIOD valid_at)

影響範圍

這項功能對需要保存歷史狀態的業務場景影響最大，包括價格歷史、合約有效期、員工職位變動、保險保障期間等。過去需要在應用程式層實作的時間切割邏輯，現在可以下沉到資料庫層，降低程式碼複雜度並減少資料不一致的風險。

目前版本有幾項值得注意的限制。時態外鍵的參考動作僅支援 NO ACTION，尚不支援 CASCADE、SET NULL、SET DEFAULT。System-time 自動追蹤（transaction-time tracking）尚未原生實作，文件指出可透過觸發器模擬，但不在本次 Beta 範圍內。使用上也必須使用 DATERANGE 等範圍型別，而非兩個獨立的 start_date、end_date 欄位，需要調整既有的資料表設計。

整體而言，PostgreSQL 19 的時態資料表支援標誌著關聯式資料庫對 SQL:2011 標準時態功能的重要補齊，讓 PostgreSQL 在這個面向追上了 Oracle、IBM Db2 等商業資料庫長期以來的原生能力。

原始來源：pgEdge — Looking Forward to Postgres 19: It's About Time；PostgreSQL 19 Release Notes