今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年6月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。
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 標準への提案も予定しているという点もまた興味深いところです。