PGConf.EU（PostgreSQL Conference Europe）は、欧州最大級のPostgreSQLコミュニティカンファレンスです。
PostgreSQLの開発者やユーザー、ベンダー企業が世界中から集まり、最新機能や開発動向、運用事例、技術的な知見を共有します。PostgreSQLコミュニティを代表する国際イベントの一つとして知られており、毎年多くの参加者が集まります。
2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。
本レポートでは、PGConf.EU 2026 Day3で発表された講演のうち、筆者が印象に残ったセッションを紹介します。
Where next for parallel query execution?
Thomas Munro 氏は、PostgreSQL の並列クエリ実行における課題と今後の改善の方向性について解説しました。
重要な課題の1つとして挙げられたのが、メモリ管理です。現在の PostgreSQL では、ソートやハッシュ結合などの処理ごとに、主に work_mem パラメータを上限値としてメモリ使用量を制御しています。
しかしながら、各処理がメモリを確保・解放するタイミングは実行計画や実行時の状況によって異なるため、単純な掛け算ではピーク時の使用量を正確に把握できず、システム全体で実際にメモリがどの程度使用されるのかを予測することは困難です。
work_mem を大きなサイズに設定すると OOM によるプロセス終了などの危険がある一方で、安全性を重視してwork_mem を小さくすると、利用可能なメモリを十分に活用できません。
特にクエリを複数プロセスで並列に実行する場合には、より多くのメモリを消費する可能性があるため、メモリ管理の重要性も高くなります。
この課題に対して、各処理ごとのメモリ管理ではなく、クエリ単位、さらにはシステム全体でメモリを管理する方向性が示されました。まず、クエリ実行時のピークメモリ使用量を計測し、EXPLAIN (ANALYZE) で表示できるようにしたり、共有メモリを通じて参照可能にすることが提案されました。さらに、プランニング時にはピークメモリ使用量を推定して EXPLAIN で表示できるようにする案も紹介されました。
また、クエリの実行開始を制御する Admission Control のアイデアも紹介されました。システム全体で利用可能なメモリ量を管理し、クエリごとに推定される使用量を事前に予約しておく仕組みです。メモリが不足する場合には、実行を待機させるか、work_mem を小さくして実行する方法が考えられています。
これらの改善は今後の検討課題ですが、もし実現すれば、並列クエリ実行において、安全性とリソース利用効率を両立した、より適切なメモリ管理につながる可能性があります。今後の動向に注目です。
The process of RPM packaging in the PostgreSQL ecosystem
Devrim Gündüz 氏は、PostgreSQL エコシステムにおける RPM パッケージの作成・保守プロセスと、その運用上の課題について解説しました。
PostgreSQL の RPM リポジトリでは、膨大な数のパッケージを管理しており、PostgreSQL 本体だけでなく、拡張機能やバックアップツールなども提供しています。
RPM パッケージの作成には、ビルド手順や依存関係、インストールするファイルなどを定義した Spec ファイルを使用します。パッケージングでは、Spec ファイルの作成に加え、依存関係の確認、セキュリティ検査、各 OS や PostgreSQL のバージョンとの互換性確認など、多くの作業が必要です。また、PostgreSQL が依存するライブラリなどのパッケージ名は Linux ディストリビューションによって異なるため、Spec ファイルには複雑な条件分岐が必要になるなど、多彩なディストリビューションにパッケージを提供しているPostgreSQLならではの苦労も語られました。
こうした作業を効率化するため、Claude などの AI を活用し、自動化ツールやテストコードの作成など、日常的なメンテナンス作業の効率化にも取り組んでいることが紹介されました。
特に印象的だったのは、RHEL の OpenSSL 更新に伴う互換性問題です。(参考: https://www.postgresql.org/about/news/postgresql-rpm-repository-now-supports-multiple-rhel-minor-versions-3202/)
2025年にリリースされた RHEL 9.7 および 10.1 では、OpenSSL のバージョン更新によって、以前のマイナーバージョン向けの RPM との間で依存関係の問題が発生しました。これを受けて、PostgreSQL の RPM リポジトリでは、RHEL 9 と 10 のそれぞれについて最新 2 つのマイナーバージョンをサポートし、マイナーバージョンごとに RPM をビルドする方針に変更しました。この対応に伴う作業負担は大きく、「ストレスの多い1月を過ごした」と語られたことが印象に残っています。
講演を通じて、RPM パッケージの提供は単なるビルド作業ではなく、OS の変更への対応や、セキュリティと品質の継続的な確保など、多くの保守作業によって支えられていることが実感できました。
Can We Skip Recovery? The Architecture of On-Demand WAL Replay
Srinath Reddy Sadipiralla 氏は、PostgreSQL のクラッシュリカバリを高速化する「On-Demand WAL Replay」の実験的なアーキテクチャについて解説しました。
現在の PostgreSQL では、クラッシュ後の起動時にリカバリが実行され、チェックポイント以降の WAL をすべて再生する必要があります。これが完了するまでクライアントは接続できないため、WAL の量が多いほどサービス停止時間が長くなる問題があります。
これを解決するために提案されている「On-Demand WAL Replay」では、起動時のリカバリで WAL すべてをスキャンする一方、テーブルやインデックスなどのデータページを変更する WAL レコードの適用を遅延させます。未適用の WAL レコードはページごとに共有メモリ上で管理し、ページへの初回アクセス時や、バックグラウンド処理によって適用されます。これにより、すべてのページの復旧を待たずにクライアントからの接続を受け付けられるようになります。
性能評価では、接続可能になるまでの時間が最大 5.5 倍高速化しました。一方で、初回アクセス時の遅延や、未復旧ページが存在する間のチェックポイントの制限、共有メモリの消費などが課題として挙げられました。今後はリプレイ処理の並列化や、管理情報のディスクへの退避などが検討されています。
講演の終わりには、本機能のバグ報告など、開発への協力が呼びかけられました。このように、開発中の機能についてフィードバックを募れることも、カンファレンスを開催する重要な意義であると感じました。
まとめ
以上、PGConf.EU 3日目の講演レポートでした。
本日最後に行われたクロージングセッションによると、今回の参加者は 747 名、講演数は 101 講演だったとのことです。改めて、規模の大きいイベントであると感じました。
3日間を通して、PostgreSQL の内部構造や新機能、運用上の課題など、幅広いテーマの講演を聴くことができました。また、講演後の活発な質疑応答や参加者同士の交流からも、PostgreSQL コミュニティの活気を感じました。技術的な知見だけでなく、今後の PostgreSQL の発展に向けた取り組みを知ることができた、有意義な 3日間でした。
