2026/02/01

PostgreSQL 18の新機能、仕様変更、不具合修正。開発者、運用管理管理者向け

 

1. PostgreSQL 18 基本情報

  • リリース日: 2025年 9月 25日

  • 主な焦点: 非同期I/Oサブシステムの導入によるI/O高速化、B-tree Skip Scan、UUIDv7のネイティブサポート、およびアップグレードプロセスの効率化。

2. 開発者向け：新機能と仕様変更

待望のインデックス・クエリ最適化

  • B-tree Skip Scan: 複合インデックス（例：col1, col2）において、先頭カラム（col1）を検索条件に含めなくても、後続のカラム（col2）のみで効率的にインデックスを利用できるようになりました。

  • UUIDv7 のネイティブサポート: uuidv7() 関数が導入されました。時系列順に並ぶ特性を持つため、B-treeインデックスの断片化を抑制し、書き込みパフォーマンスを向上させます。

  • 仮想生成列 (Virtual Generated Columns): 値をディスクに保存せず、クエリ実行時に計算する「仮想」列がサポートされ、デフォルトの挙動となりました。ストレージ容量を節約できます。

表現力の向上

  • RETURNING句の拡張: UPDATE 時に RETURNING old.col, new.col のように記述することで、変更前と変更後の値を同時に取得できるようになりました。監査ログの実装などが非常に容易になります。

  • SQL/JSON 構築関数の強化: JSONオブジェクトや配列の作成において、より柔軟な標準SQL準拠の構文が追加されました。

3. 運用管理担当者向け：新機能と仕様変更

アーキテクチャの進化

  • 非同期I/O (AIO) サブシステム: io_method 設定により、Linuxの io_uring やワーカープロセスを用いた非同期I/Oが利用可能です。特にクラウド環境などのネットワークストレージにおいて、読み取り性能が最大2〜3倍向上します。

  • パラレルCOPY: COPY FROM によるデータインポートが並列実行可能になり、大規模データのロード時間が大幅に短縮されました。

アップグレード・メンテナンスの改善

  • 統計情報の引き継ぎ: pg_upgrade 実行時にクエリプランナー用の統計情報が新しいクラスタへ引き継げるようになりました。アップグレード直後の ANALYZE 待ちによる性能劣化問題が解消されます。

  • パラレルGINインデックス作成: 全文検索などで多用されるGINインデックスの構築が並列化され、作成時間が劇的に短縮されました。

  • OAuth 2.0 認証: シングルサインオン（SSO）環境との統合を容易にする OAuth 2.0 認証がネイティブでサポートされました。

4. V18で修正された不具合

メジャーリリースおよび初期マイナーリリース（18.1）にて、以下の重要な修正が行われています。

  • ハッシュ結合のメモリ制御修正: ハッシュテーブルのサイズ選択ロジックに誤りがあり、必要以上のメモリを消費する、あるいは非効率な割り当てが発生していた問題が修正されました。

  • GINインデックスの無限ループ修正: 複数のスキャン条件（特に否定条件 ! term など）を組み合わせた際に、稀に無限ループに陥る不具合が解消されました。

  • PL/Pythonのメモリリーク: SQLエラー処理時にセッションメモリが解放されない不具合が修正されました。

  • 共有統計情報の破損防止: メモリ不足（OOM）エラー発生後に、統計情報を管理する共有テーブルが破損する可能性があった問題が修正されました。

5. 重要な仕様変更と互換性（注意点）

  • io_method のデフォルト: デフォルトは従来の挙動に近い設定ですが、io_uring を利用するにはカーネルの対応と設定が必要です。

  • パーティションテーブルの UNLOGGED 制限: パーティション親テーブルを UNLOGGED に設定する操作がエラーになるよう変更されました（パーティション個別に設定する必要があります）。

  • EXPLAIN のデフォルト変更: EXPLAIN ANALYZE を実行すると、BUFFERS（バッファ使用量）の情報が明示的に指定しなくてもデフォルトで表示されるようになりました。

  • 生成列のデフォルト変更: GENERATED ALWAYS 列がデフォルトで VIRTUAL（非保存）として扱われるため、従来の STORED（保存型）を期待するスキーマ定義は注意が必要です。

6. V17からV18へのアップグレード失敗談

最新バージョンへ移行した現場からの「落とし穴」事例です。

① 「非同期I/O設定によるリソース食い潰し」

  • 現象: 性能向上を狙って io_method = io_uring を有効にしたが、OS側の max_worker_processes やファイル記述子の制限を超えてしまい、データベースが起動しなくなった。

  • 教訓: AIOは強力ですが、OSレベルのチューニングとセットです。検証環境で I/O ワーカー数とOSリソースの整合性を必ず確認しましょう。

② 「統計情報引き継ぎの過信」

  • 現象: pg_upgrade で統計情報を引き継いだが、V18で導入された「Skip Scan」や「OR/IN 最適化」の影響で、一部のクエリプランが意図せず変わり、逆に遅くなった。

  • 教訓: 統計情報の引き継ぎは「アップグレード直後の最悪な状態」を避けるためのものです。新機能によるプラン変更を確認するため、本番稼働前には改めて主要クエリの実行計画を確認すべきです。

③ 「RETURNING句の既存コード競合」

  • 現象: アプリケーション側で old や new という名前のカラムを使用していたため、V18の新しい RETURNING 構文のキーワードと衝突し、クエリがエラーになった。

  • 教訓: 予約語に近い列名を使用している場合、V18の構文拡張が影響しないか、事前の構文チェックが推奨されます。

時刻:
ラベル: