2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EUで発表された講演のうち、筆者が印象に残ったセッションを紹介します。

オープニングセッション

オープニングセッションでは、イベントの説明がされたのち、PostgreSQLとPostgres Europeの30年にわたる歴史を振り返りました。1996年頃のPostgreSQL 6.0から始まり、2008年のPostgres Europe設立、2014年のマドリード開催、コロナ禍を経たカンファレンスの復活などの紹介がありました。一番重大なトピックとして、PostgreSQL EUのマスコットとしてSlonikというマスコットキャラクターがいるのですが、今年その着ぐるみが代替わりしたそうです。新しいSlonikマスコットのお披露目や旧着ぐるみの抽選企画も発表され、会場は笑いに包まれました。

 REPACK in Core

Robert Treat 氏による、PostgreSQL 19 に導入予定の REPACK コマンドについての解説です。
PostgreSQL では、MVCC によってテーブルやインデックスが肥大化することがあります。いったん肥大化したテーブルは通常のVACUUMでは縮小できず、強いロックが必要なVACUUM FULLを実行する必要があります。

PostgreSQL 19では、VACUUM FULLの名前がREPACKに変更されました。このことにより、通常のVACUUMとの区別がしやすくなるという利点があります。
また、REPACK CONCURRENTLY機能が追加され、通常のデータベース操作への影響を抑えながら再編成できます。

REPACK CONCURRENTLY は、論理デコードを利用して更新を追跡しながら、新しいテーブルへデータをコピーします。最後に短時間の排他ロックを取得してファイルを切り替える仕組みです。

ただし、長時間トランザクションとの競合や MVCC 安全性、REPACK実行中の更新行数の上限、メモリ消費など、運用上の制約が残っています。また、実行できないテーブルもあり、複数のREPACK CONCURRENTLYを同時に実行することも推奨されていません。

講演者は、現時点では既存の pg_repack を完全に置き換えるものではないと説明しました。特に、多数のテーブルを定期的に再編成する用途では、引き続き pg_repack が有用です。

制約が多数あり、PostgreSQL 19時点では本番環境で実行することは難しい機能だと感じました。しかし、テーブルへの更新や参照をブロックしないテーブル再編成機能はニーズの高い機能であり、PostgreSQL 本体にREPACK CONCURRENTLY機能が導入されることは大きな進歩です。今後の改善が期待されます。

pg_ivm の最近の改善と方向性

弊社の長田からは、PostgreSQL のマテリアライズドビューを高速に更新するための拡張モジュール pg_ivm の最近の改善と今後の方向性について紹介されました。

pg_ivm は、Incremental View Maintenance（増分ビューメンテナンス）を PostgreSQL 上で実現する拡張機能です。通常のマテリアライズドビューでは、基となるテーブルの更新内容を反映するために REFRESH MATERIALIZED VIEW を実行してビュー全体を再計算する必要がありますが、pg_ivm は変更差分のみを計算して適用することで、自動的かつ効率的に再更新されるマテリアライズドビュー（IMMV, Incrementally Maintainable Materialized View）を作成することができます。

講演では、増分メンテナンスによってビュー更新を高速化できる一方、元テーブルの更新時には差分計算やビュー更新が発生するため、一定のオーバーヘッドや同時実行性への影響があることも説明されました。

最近の機能改善としては、Outer Join（外部結合）のサポート、pg_dump および pg_upgrade への対応強化、PostgreSQL 19 への対応などが紹介されました。特に Outer Join のサポートが大きな技術的成果として取り上げられました。Outer Join では、結合相手が存在しない場合に生成される NULL で補完された行（dangling tuple）が存在するため、単純な増分メンテナンスでは適切に対応できません。pg_ivm では、Outer Join の結果を 通常の内部結合で得られる部分と、結合相手を持たない行に影響する部分に分けて扱うことで対応しています。また、以前は pg_dump によるダンプデータのリストア時やpg_upgrade によるアップグレード後にpg_ivmのメタデータが正しく復元されない問題がありました。これらについても、メタデータを復元する関数を実装することなどにより、適切にデータ移行できるように改善されました。

今後の開発では、Deferred Maintenance（遅延メンテナンス）が大きな候補として挙げられました。テーブル差分の収集とビューの更新を分離し、後からまとめてメンテナンスできるようにすることで、テーブル更新性能への影響を軽減しながら、増分メンテナンスの利点を活用できるようになることが期待されます。

Community Moments That Shaped 30 Years of PostgreSQL

Valeria Kaplan 氏による、イベントを通じて発展してきた PostgreSQL コミュニティの歴史を振り返るセッションです。 PostgreSQL は、1990 年代の開発者同士の交流から成長し、現在では世界各地でカンファレンスやミートアップが開かれています。

PostgreSQLの開発はメーリングリスト上で行われていると思われていますが、実はこのようなコミュニティイベントによる交流の力も大きいです。メーリングリストだけでは生まれにくい信頼関係や協力関係を育むことで、新機能の開発につながっています。

コミュニティイベントの開催は主に企業、登壇者、運営者によって支えられています。企業はイベント協賛の形で資金提供を行いますが、イベントへの協賛は、人材採用や認知度向上、開発動向の把握に役立ちます。一方、登壇者は講演を準備する労力を支払う一方で、知識の共有や成長の機会を得られます。運営者は多くの時間と労力を費やしますが、コミュニティに貢献する誇りや仲間とのつながりが活動を支えています。

今後の課題として、新しい登壇者や運営ボランティアの参加を増やしていくこと、多様性を向上させること、学生や他の技術コミュニティとの交流を拡大することが挙げられました。講演者氏は、小さな貢献でも大きな変化につながる可能性があるとして、積極的な参加を呼びかけています。PostgreSQLの発展にはコミュニティへの貢献が不可欠ですので、筆者も何らかの形で貢献したいと考えています。

明日は、Conference Day2の様子をお届け予定です。
ぜひSRA OSS Tech Blog のブックマークのほどよろしくお願いいたします！