今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年9月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。
PostgreSQL 19 で相次いだ機能の差し戻し
PostgreSQL 19 のリリースを目前に控えた9月は、複数の新機能が差し戻し（revert）されるという異例の月となりました。
まず、SQL標準のプロパティグラフ問い合わせ機能である SQL Property Graph Queries (SQL/PGQ) が差し戻されています。この機能では、グラフを構成する頂点や辺、ラベル、プロパティなどをシステムカタログで管理していました。しかし、それに伴って依存関係が複雑化し、グラフ削除後に不要なメタデータが残る問題や、ダンプ・リストア時の問題などが報告されていました。議論では、既存の依存関係管理の仕組みそのものを見直す必要があるのではないかという意見も出て差し戻しとなりました。
また、Temporal Table 機能の一部である UPDATE/DELETE FOR PORTION OF も差し戻されました。この機能はレコードが持つ期間情報の一部分のみを更新または削除するものですが、それによって残りの期間を表す新しい行が発生します。この新しく生成された行が、READ COMMITTED 分離レベルで並行実行される更新処理から適切に認識されず、その結果として更新結果が失われる Lost Update 発生の可能性が受け入れがたい問題として捉えられました。
さらに、外部キー参照整合性チェック高速化機能のうち、複数行をまとめて確認するバッチ処理部分が差し戻されています。外部キー参照整合性チェックの高速化は、チェックを SQL 実行ではなく直接インデックス検索で行うことによる性能改善ですが、複数行をまとめて処理する際のスナップショット取得タイミングや、他の機能との相互作用によって不整合が生じる可能性が指摘されていました。そのためバッチ処理部分が差し戻されましたが、1行単位で実行する高速化部分は維持されています。
このほか、オンラインでデータチェックサムを有効化・無効化する機能についても、コミット後に多数の修正が必要となったことから差し戻しが行われました。
グラフ処理や Temporal Table 機能など、データベースとしての可能性を広げる機能が差し戻しとなったのは残念ではありますが、これら新しい機能実装と、既存機能との相互作用や依存関係管理、並行実行制御といった PostgreSQL の深い部分との関わりが表面化した例として興味深く感じました。
TOAST の改善
一方で、PostgreSQL 20 に向けた開発として、TOAST 関連の改善が進展しています。
TOAST とは PostgreSQL で大きなデータをテーブルに格納するための基盤で、データを圧縮・分割して専用の TOAST テーブルへ格納します。その管理に利用する OID（Object ID） を従来の 4 バイトから 8 バイトへ拡張する機能がコミットされました。
従来の 4 バイトの TOAST OID では、大量のデータを扱うシステムでは枯渇する可能性があり、データ行の挿入時に未使用 OID を探索する必要があり、そのオーバーヘッドによる性能低下も課題となっていました。新しい方式ではテーブル単位のオプションによって 8 バイト OID を利用できるようになり、未使用 OID を探索する必要がなくなることから性能改善も期待されています。
また、TOAST の圧縮方式拡張も議論されています。現在利用できる圧縮方式は pglz と lz4 の2種類のみですが、将来的により多くの圧縮方式を追加できるようにするための基盤整備が提案されています。最初の追加候補としては ZSTD が予定されています。
圧縮プロトコル
通信性能改善に関する提案として、プロトコル圧縮にも進展がありました。
これは、バックエンドからフロントエンドへ送られるデータを圧縮する提案です。過去の議論でカバーする機能を広げすぎて合意に至らなかった反省から、今回は機能を絞る方向で議論が進められています。対象となるのはSELECT や COPY 文で送られる行データで、圧縮方式としては ZSTD のみをサポートする方向で検討されています。また、コネクションプーラとの互換性を維持するため、トランザクション境界で圧縮フレームをリセットする仕組みも議論されています。
UNDO ログエンジン
リカバリ関連では、新しい UNDO ログエンジンの提案がありました。
PostgreSQL は REDO ログ（WAL）を中心とした設計を採用しており、トランザクションの変更を取り消すための UNDO ログは持っていません。そのため、更新・アボートの繰り返しでテーブルやインデックスが膨張したり、クラッシュ時に作成途中のファイルがディスク上に残る（孤立ファイル問題）が課題となっていました。過去にも zheap など UNDO ログベースのテーブルアクセスメソッドの提案がありましたが、今回の提案は新しいテーブルアクセスメソッドから出発するのではなく、まず汎用的な UNDO 基盤を用意しようというアプローチです。
提案では、共通の UNDO 情報は通常の WAL に記録し、アクセスメソッド固有の UNDO 情報は別領域で管理します。また、アボートされたトランザクションや UNDO の進捗を一元管理し、実際の UNDO 処理はバックグラウンドで実行することで、高速なリカバリの実現を目指しています。
まずは UNDO ログを用いた孤立ファイルの削除やアボート済みデータの回収を対象とした機能を先行して実装し、その後に新しいテーブルアクセスメソッドへの応用を検討する構想となっています。新しいテーブルアクセスメソッドから作るのではなく、UNDOログのための新基盤の整備から始めるという方向性は興味深いものに感じました。
ブルームフィルタによるハッシュ結合改善
以前にも紹介した、ブルームフィルタ（Bloom Filter）を利用したハッシュ結合の改善についても引き続き議論が続いています。
これは、ブルームフィルタを利用することで、結合先に存在しない行をスキャン段階で除外できるため、大幅な性能向上が期待できるという提案ですが、9月には、プランナにおけるブルームフィルタ適用後の行数の見積もりについて議論されていました
提案の一つでは、ブルームフィルタを近似的な semi-join （結合先に存在する行だけを残す結合）とみなしてコストベース最適化へ組み込む方法が示されています。これは、SIGMOD 2025 で発表された論文（Including Bloom Filters in Bottom-up Optimization）を参考にしたものです。一方で、コストベースの最適化では正確な行数推定は難しくプラン処理も複雑になるという意見も出されています。その回避策の実例として、実行時に実際のデータを見て振る舞いを動的に調整する SQL Server の実装について紹介した論文（I Can’t Believe It’s Not Yannakakis: Pragmatic Bitmap Filters in Microsoft SQL Server, CIDR 2026）が引き合いに出されていました。そうした懸念から、プランナではブルームフィルタの存在は考慮せず実行時に可能ならば適用する方式を推す声も上がっています。
PostgreSQL のプラン処理にブルームフィルタの存在をどのように組み込むかという議論は、理論と実装をどう結びつけるかという観点からも興味深いと感じており、今後も注目していきたいと思います。