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 のプラン処理にブルームフィルタの存在をどのように組み込むかという議論は、理論と実装をどう結びつけるかという観点からも興味深いと感じており、今後も注目していきたいと思います。

PostgreSQL 19 リリースにむけて

PostgreSQL 19 のリリースに向けた準備が進められています。PostgreSQL のメジャーリリースのリリースノートには、開発だけではなくレビューや開発報告など何らかの形での貢献者の名前リストが掲載されます。これらの名前について、表記揺れや重複、姓と名の順序などを確認する作業が行われました。なお、SRA OSS からも6名（８月時点）の貢献者の名前が含まれています。

一方で、リリース予定機能についてはやや緊迫した状況となっています。きっかけとなったのは、主要開発者の Robert Haas が AI（Claude）を利用して最近の不具合報告を整理し、多数の問題報告が集まっている機能を洗い出したことでした。対象となったのは、外部キー制約の高速化、REPACK / REPACK CONCURRENTLY コマンド、オンライン・データチェックサム有効化、SQL Property Graph Queries（SQL/PGQ）など、PostgreSQL 19 の主要機能です。議論では、それぞれについてリスクを評価し、機能全体または一部を差し戻すべきかどうかが検討されています。

興味深かったのは、こうした状況の背景として、「AI の普及によって従来よりも不具合が発見されやすくなった可能性がある」という意見も出ていたことです。PostgreSQL に限らず、OSS 開発のあり方が変化しつつあることを感じさせる議論でした。

SSIで相次いで報告された不具合

新機能ではなく、長年存在する機能に関する議論として、SERIALIZABLE 分離レベルを実現するための仕組みである、シリアライザブルスナップショット分離（SSI）に関する不具合が多数報告されました。ここ最近で SSI に関係する不具合が合計7件報告され、それぞれについて修正案が議論されています。報告された問題には、一意性制約をすり抜けて主キー重複が発生する可能性があるものや、SAVEPOINT の ROLLBACK 時に直列化異常の情報が失われる可能性があるものなどが含まれています。

SSI は PostgreSQL のトランザクション制御機構の中でも特に複雑な部分の一つです。これらの問題はもともと別々のスレッドで報告されたものですが、開発者の Andrey Borodin によって一つのスレッドへ整理されており、SSI の内部動作や課題を理解するための良い手がかりとなっています。

INSERT SELECT のパラレル化

性能改善に関する議論では、INSERT SELECT のパラレル化に進展がありました。

INSERT SELECT は、SELECT 文の結果をテーブルに挿入するための構文ですが、この SELECT の実行部分をパラレル化することで、大量データのロードを高速化しようという提案です。しかし、テーブルへの挿入時には、トリガや制約、デフォルト値、生成列などの処理が実行される可能性があり、それらを並列実行しても安全かどうかを確認する必要があります。この確認処理自体がオーバヘッドとなり、巨大なパーティションテーブルなどでは特にそれが顕著となります。

この問題に対し、ユーザ自身が事前にテーブルを「並列安全」と宣言する方式も提案されていましたが、その場合はユーザに全ての責任を負わせることになるため、好ましくありません。これに対して8月には、並列安全性を初回アクセス時に自動計算し、その結果をキャッシュする方法が提案されました。さらに、適切なキャッシュの無効化や、SELECTを並列実行した結果を一旦全て一時ファイルに保存してからテーブルに挿入する方式とのハイブリッドなど、さらなる改善の議論が続いています。

リカバリのパイプライン化

もう一つ注目した性能改善提案が、リカバリ処理のパイプライン化です。これは、PostgreSQL のリカバリ（クラッシュリカバリ、アーカイブリカバリ）時に WAL の適用を高速化するための提案です。

現在の PostgreSQL では、リカバリを担当する「startup プロセス」が、WAL の読み込み、デコード、適用をすべて担当しています。提案では、WAL のデコードを専用のバックグラウンドプロセスへ分離し、startup プロセスは WAL の適用に専念する構成となっています。つまり、WAL レコードの生成と消費を異なるプロセスで担当するパイプライン構造であり、これによって、リカバリ処理を20〜42%程度高速化できることが報告されています。

8月には、ロック競合によるオーバーヘッドの削減や、プロセス間シグナル通信の最適化、不正な WAL を検出した場合の責任分担などについて議論が行われました。リカバリアーキテクチャそのものを見直す提案として興味深く感じています。

VACUUMを妨げる要因を可視化する pg_xmin_horizon

運用に関する提案としては、新しいシステムビュー pg_xmin_horizon の議論に進展がありました。

PostgreSQL を運用していると、不要データを削除する VACUUM が期待通りに進まないことがあります。その原因としては、長時間実行中のトランザクションやレプリケーションスロット、プリペアドトランザクションなどが考えられます。現在も既存のシステムビューを組み合わせることで調査は可能ですが、それぞれの情報取得タイミングが異なるため、必ずしも正確な状況を把握できるとは限りません。

pg_xmin_horizon は、そのような要因を単一のビューで確認できるようにする提案です。このビューには、VACUUMを妨げている要因（バックエンドプロセス、レプリケーションスロット、プリペアドトランザクション、など）や、その要因によって VACUUMがどこで止められているか、要因となっているトランザクションのIDはなにか、などの情報が含まれています。8月には、表示情報の追加やテスト強化、ドキュメント整備などが進められていました。運用時のトラブルシューティングに役立つ機能として期待できそうです。

エグゼキュータ・プランナ関連

SQL の実行を担当するエグゼキュータにおけるバッチ処理実装に関する進捗がありました。現在の PostgreSQL のエグゼキュータは、テーブルページからタプル（行）を1行ずつ取得して処理しています。しかし、この方式では関数呼び出しなどのオーバーヘッドが大きいという課題があります。一方、ページ内の複数タプルをまとめて取得するバッチ処理に対応できれば、CPU の SIMD （1つの命令で複数のデータを同時に処理する）命令を利用した最適化なども可能となり、大きな性能向上が期待されています。

この提案は2025年から議論が続いていますが、その間にアーキテクチャも変化してきました。当初はバッチ処理用にタプルを格納する「タプルスロット」を複数を用いる設計でしたが、管理コストが課題となり、その後はスロットを1つだけ用いて複数タプルを参照する方式へ変更されました。そして7月には、新しいデータ構造を導入する代わりに既存のタプルスロットへバッチ管理機能を追加する、よりシンプルな設計が提案されています。この実装では、ワークロードによって20〜40%程度の性能向上が報告されています。さらに、別の開発者からは API の変更を伴わない別アプローチも提案されるなど議論が続いています。

同じく性能改善に関する提案として、ブルームフィルタ（Bloom Filter）を利用したハッシュ結合の高速化も議論されました。ハッシュ結合は、結合先テーブルから構築したハッシュ表を利用して結合相手を高速に探す結合アルゴリズムです。また、ブルームフィルタは、集合に要素が含まれていないことを高速に判定できる確率的データ構造です。この性質を利用して、ハッシュ表に結合先が存在しないことが分かるタプルを、ハッシュ結合より前の順スキャンやインデックススキャンの段階で除外することで、処理対象行数を大幅に削減できます。さらに、実行計画の改善やキャッシュ効率の向上、外部キー制約との組み合わせなどについても議論されており、ワークロードによっては1.5倍から最大10倍程度の性能向上が報告されています。複数の開発者が共同でパッチを改善していく形で活発に議論が進められています。

論理レプリケーション

論理レプリケーション関連では、競合（conflict）情報を専用テーブルへ保存する機能に動きがありました。本格的なサポートに向けた基盤として、競合ログテーブルを作成する機能が先行してコミットされています。CREATE SUBSCRIPTION の新しい conflict_log_destination オプションに table または all を指定すると、pg_conflict スキーマ内に pg_conflict_log_<subid> という名前のログテーブルが自動的に作成されるようになりました。

一方で、実際に競合情報をテーブルに書き込む機能については引き続き議論が続いています。現在の設計では、一意性制約違反などで発生した ERROR を一旦捕捉し、競合情報を記録した後に再度エラーを発生させる方式となっています。しかし、このような例外処理によるトランザクション終了方法に対して安全性の懸念が示され、設計の見直しが議論されています。

また、PostgreSQL 19 の新機能であるシーケンス同期について不具合が見つかり、Open Item として議論されました。ALTER SUBSCRIPTION … REFRESH SEQUENCES コマンドは、サブスクライバ側のシーケンス値をパブリッシャ側と同期する機能ですが、シーケンス同期の実行中に再度コマンドが実行されると、新しい要求が反映されない競合状態がありました。一度は同期実行中のコマンド実行を禁止する修正がコミットされましたが、ユーザビリティの観点から見直され、最終的には実行中の同期処理を中断して、新しい要求に基づいて同期をやり直す、という方法で解決されました。

SQL構文関連

SQL 構文に関する話題もいくつかありました。

まず、PostgreSQL 19 でサポート予定だった GROUP BY ALL 構文が見送られることになりました。これは、SELECT 文において集約関数やウィンドウ関数に含まれない項目を自動的に GROUP BY 対象とする便利な構文ですが、ORDER BY USING と組み合わせた場合にセマンティクス上の問題が見つかったため、PostgreSQL 19 への導入は断念され、PostgreSQL 20 以降で改めて検討されることになりました。

また、次期 SQL 標準に採用された INSERT BY NAME 構文の提案も行われました。これは、「INSERT INTO tbl (x, y) BY NAME SELECT 1 AS y, 2 AS x FROM …」のように列の位置ではなく列名を基準に挿入される列の対応付けを行う構文で、Oracle や DuckDB などでも同様の機能がサポートされています。

少し変わった提案として、「FROM tbl SELECT *」のように FROM 句を SELECT 句より前に記述する「FROM ファースト構文」も投稿されました。このパッチは PostgreSQL の開発者向け教育課題として作成されたもので、投稿者自身も本当の動機は 「ただ楽しいから（”just for fun”）」 と説明しています。しかしその一方で、SQL の記述が簡潔になることや、psql コマンドのタブ補完を改善しやすいこと、DuckDB や ClickHouse など他の DBMS との互換性といった利点も挙げられており、予想以上に盛り上がりを見せた議論となっていました。

Commit Sequence Numbers（CSN）スナップショット

5月末には、カナダ・バンクーバーで PostgreSQL の開発者やユーザ、コミュニティ関係者が集まるイベント PGConf.dev 2026 が開催されました。そこでのアンカンファレンスのセッションに引き続いて、Commit Sequence Numbers（CSN）を用いたスナップショット管理について議論されていました。

現在の PostgreSQL では、ある時点で実行中のトランザクション ID のリストを取得することでテーブル行の可視性（クエリ中に行が取得できるかどうか）を判定しています。一方、CSN ベースでは各トランザクションにコミット順を表す番号を付与し、それを基準に可視性を判断します。この方法では、スナップショット取得を高速化できるほか、プライマリとスタンバイで可視性判定が異なってしまう現象（ Long Fork アノマリ）を回避できるなどのメリットがあります。その一方で、同期コミットと非同期コミットを組み合わせた場合の可視性判定に課題があり、これを解決する方法についても議論が行われていました。

プランナ関連の議論

今月もプランナ関連での興味深い議論がいくつかありました。

一つは、外部キー制約を利用して不要な内部結合を削減する最適化です。外部キー制約の下において結合先テーブルが結果に影響しない場合には、そのテーブルのスキャンを省略できるため、特に多段結合を伴うグラフクエリなどで大きな性能向上が期待されます。一方で、PostgreSQL の外部キー制約は AFTER トリガで実装されているため、制約が一時的に満たされないタイミングがあり、その場合への対応方法について PGConf.dev 2026 での議論を踏まえて整理・議論されていました。また、同じ開発者からは、LEFT JOIN や FULL JOIN をより効率的な ANTI JOIN プランに内部的に変換する最適化手法も提案されており、結合処理全体の最適化に向けた取り組みが続いています。

また、拡張統計情報（多重列 MCV）を利用した行数推定精度の改善についての議論がありました。検索条件の組み合わせが統計情報に存在しない場合でも、最頻値リストの性質を利用してより精度の高い行数推定を行う提案で、より効率の良い実行計画の生成を目指しています。

さらに、EXPLAIN に表示されるサブプラン名の改善も提案されました。この改善は私が提案したもので、最適化によって EXISTS 句が ANY サブプランへ変換された場合に、それぞれに区別しやすい名前を付けることで、実行計画の可読性向上や pg_plan_advice で実行計画を制御する際の利用性向上を目的としています。

論理レプリケーション

論理レプリケーション関連では、5月に続き競合情報（conflict）を専用テーブルへ保存する機能の議論が継続しました。6月は pg_dump の実行を考慮したロック制御や、競合情報を保存するデータ型として JSON 型を使用することなどが議論されました。

DDL レプリケーションについても継続的な議論が行われました。これまでの提案では、1つの DDL が複数のコマンドへ分割されるケースがありましたが、6月にはこれを単一の JSON 表現へ変換するための共通インフラが提案されました。この仕組みは DDL レプリケーションだけではなく他用途での利用も想定されるため、独立した基盤として議論が進められています。また、本体への実装とは別に、拡張モジュールを使ってDDLレプリケーションを実現可能とするための新しいフックが、具体的な contrib モジュールとともに提案されていました。

それ以外の議論

グローバル一時テーブル（Global Temporary Tables）を実装する提案が再び始まりました。グローバル一時テーブルは、テーブル定義は永続化されて全セッションから共有される一方で、格納されるデータは各セッションごとに独立した一時データとして扱われる仕組みです。実はグローバル一時テーブルは過去にも提案されたテーマなのですが、今回は新しい設計によるパッチセットで改めて議論が始まっています。さらに、今回のパッチの投稿者とは別に、同時期に同様のパッチセットを準備していた別の開発者とも共同で議論を進めるなど、コミュニティ内で継続的に関心のあったテーマであることが伺えます。

また、新しい SQL 構文として Key Joins の提案もありました。これは外部キー制約に基づく結合であることを SQL 上で明示し、意図しない結合による行の生成を事前に防ぐことを目的としています。該当する外部キー制約がない場合にはクエリがエラーとなります。この構文は PostgreSQL 独自機能にとどまらず、SQL 標準への提案も予定しているという点もまた興味深いところです。

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 と同じ順序関係を保つため、、既存インデックスを活用しながらソート処理を省略できるケースが生まれます。これが実現すれば一部のクエリで性能向上が期待できそうです。