pgsql-hackersウォッチ(2026年5月)

今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年5月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。

PostgreSQL 19 の Open Items

6月4日に PostgreSQL 19 Beta 1 がリリースされましたが、5月中は正式リリースに向けて解決すべき Open Items の議論が活発に行われていました。

その一つが、PostgreSQL 19 の新機能である REPACK コマンドです。REPACK はテーブルを再編成して空き領域を回収する機能で、従来の VACUUM FULL や CLUSTER に代わる新しいコマンドです。特に CONCURRENT オプションを利用すると、テーブルへのアクセスを継続したまま処理を実行できます。

5月には、REPACK CONCURRENTLY が長時間実行された場合に古い WAL が削除されなくなる問題が解消されました。一方で、処理終盤のロック昇格時にデッドロックが発生し、長時間の処理結果が失われる可能性については引き続き議論が行われています。

また、SQL標準のプロパティグラフ機能である SQL Property Graph Queries (SQL/PGQ) については、特定条件下で内部エラーが発生する問題が報告されました。

さらに、レコードごとに有効期間(application time)を持つテーブルに対する UPDATE/DELETE FOR PORTION OF 構文についても、トリガや生成列、継承テーブルなど他機能との組み合わせに関する問題が Open Items として残っています。これらの問題は、PostgreSQL 19 の正式リリースまでに解決されることが期待されています。

PostgreSQL 20以降に向けた議論

論理レプリケーション関連では、競合(conflict)発生時の情報を専用テーブルに記録する機能が議論されました。現在も競合情報はログに出力できますが、この提案では SQL から検索可能な専用テーブルへ保存できるようになります。5月は主にアクセス権限や管理方法が議論されており、システム管理用スキーマ内に専用テーブルを作成し、ユーザによる変更を制限する方向で検討が進められていました。具体的にはユーザからのINSERTやUPDATEは禁止し、メンテナンス目的のDELETEとTRUNCATEのみを許可する方針となっています。

プランナ関連では、新しい結合順序最適化手法である GOO(Greedy Operator Ordering)が興味深い話題でした。GOO は、1998年に発表された Leonidas Fegaras による論文 “A New Heuristic for Optimizing Large Queries” に基づく手法です。現在 PostgreSQL は、結合対象テーブル数が少ない場合は動的計画法(DP)によって最適な結合順序を探索し、多い場合は計算量を抑えるために遺伝的クエリ最適化(GEQO)を利用しています。しかし GEQO には計画生成時間や非決定性といった課題があります。一方、GOO は「最もコストの低い結合ペアから順に選択する」というヒューリスティック手法で、最適性は保証されていませんが、高速かつ決定論的に動作することが特徴です。ベンチマーク結果では GEQO より高速で、統計情報の変化に対しても安定した結果が得られることが報告されていました。また、一定の探索予算までは厳密な動的計画法を利用し、その後 GOO に切り替えるハイブリッド手法についても議論が行われていました。最適解の保証と計画生成時間のバランスをどのように取るかという観点で興味深く、今後の議論にも注目していきたいと思います。

その他、EXPLAIN ANALYZE に関数内やトリガ内で実行されたクエリの実行計画を表示するための NESTED_STATEMENTS オプションの提案がありました。

また、弊社顧問の石井達夫が取り組んでいる Row Pattern Recognition については、イベント列の中から特定のパターンを SQL で検索できる標準機能に向けて、FIRST/LAST 関数のサポートや JIT コンパイル対応などの進展がありました。

私が取り組んでいる Incremental View Maintenance (IVM) についても動きがありました。IVM はマテリアライズドビュー全体を再計算するのではなく、更新差分のみを反映することで高速なビュー更新を実現する技術です。5月は、拡張モジュール版の実装であるpg_ivm で行われた修正の取り込みに加え、レビューしやすくするためのパッチサイズ削減の提案を行いました。また、ビュー更新のタイミングや実装箇所などの設計上の論点を整理し、今後の議論に向けて共有しました。