今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年7月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。
エグゼキュータ・プランナ関連
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 との互換性といった利点も挙げられており、予想以上に盛り上がりを見せた議論となっていました。