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 で行われた修正の取り込みに加え、レビューしやすくするためのパッチサイズ削減の提案を行いました。また、ビュー更新のタイミングや実装箇所などの設計上の論点を整理し、今後の議論に向けて共有しました。

PostgreSQL 19の主な話題

4月には PostgreSQL 19 のリリースノート案が公開されました。

主な新機能としては、テーブルを再編成して空き領域を回収する REPACK コマンド、ストリーミングレプリケーション環境で、プライマリ上の特定の変更がスタンバイに適用されるまで待機できる WAIT FOR 文、SQL標準で定義されたプロパティグラフ検索機能である SQL Property Graph Queries (SQL/PGQ) のサポートなどがあります。

運用面では、データチェックサムを再起動なしで有効化できるようになったほか、自動VACUUMで並列ワーカーを利用できるようになりました。また、自動 VACUUM の処理対象テーブルに優先順位を設定できるようになるなど、運用性の改善も進んでいます。

論理レプリケーションでは、シーケンス値のレプリケーションや、wal_level が replica の場合でも必要に応じて論理レプリケーションを自動的に有効化する機能が追加されました。

また、実行計画の安定性向上を目的とした拡張モジュールである pg_plan_advice や、プランアドバイスの自動適用を行う pg_stash_advice も PostgreSQL 19 に含まれています。

性能改善としては、外部キー参照処理の高速化も注目されます。従来は参照先テーブルの確認のために SQL を実行していましたが、適用可能なケースでは直接システムカタログを参照するようになり、オーバーヘッドが削減されています。

また、私が開発した機能として、拡張統計情報で仮想生成列を利用できるようになりました。

PostgreSQL 20以降に向けた議論

PostgreSQL 20以降に向けた話題として、大きなものの一つが論理レプリケーションにおけるDDLサポートです。PostgreSQL の論理レプリケーションでは現在DDLは自動的には伝播されないため、そのサポートは以前から要望されている機能の一つです。

これまでの提案では、DDLの内容をJSON形式で表現してWALへ記録し、レプリケーションする方式が検討されていました。しかし、JSONベースの実装では保守コストが高くなることが課題となっていました。これに対し、JSONではなくDDLを表現する専用の抽象データ型を導入し、それをWALへ格納する新しい方式が議論されました。また、現在提案されている DDL の内容をWALに記録するのに、イベントトリガを用いる方法の是非についての議論もありました。

また、現在私が提案している機能として、テーブルロックを取得できずにスキップされた VACUUM や ANALYZE を統計情報に記録する機能があります。Autovacuum が起動したにもかかわらず実際には VACUUM や ANALYZE が実行されていない状況は、現在の統計情報だけでは把握が困難です。この機能では、pg_stat_all_tables にスキップされた VACUUM/ANALYZE の回数や時刻を追加することで、そうした状況を利用者が把握しやすくすることを目的としています。

プランナ関連では、SLOPE と呼ばれる興味深い提案もありました。これは、単調増加または単調減少する関数を含むクエリに対する最適化手法です。例えば、timestamp 型のカラム ts にインデックスが作成されている場合、date_trunc(‘month’, ts) の順序も ts と同じ順序関係を保つため、、既存インデックスを活用しながらソート処理を省略できるケースが生まれます。これが実現すれば一部のクエリで性能向上が期待できそうです。