【テクニカル・上級編】インデックスページレイアウト – PostgreSQL

PostgreSQLの深淵：インデックスページレイアウトが教えてくれる「高速化の正体」

PostgreSQLを使い始めて数年、「インデックスを貼れば速くなる」という事実は誰もが知っています。しかし、そのインデックスの内部がどうなっていて、なぜ特定のクエリでパフォーマンスが頭打ちになるのか。そこまで深く掘り下げたことがあるエンジニアは、実はそう多くありません。

今日は、PostgreSQLのB-treeインデックスの心臓部、すなわち「ページレイアウト」の話をしようと思います。ここを理解すると、単なるオペレーションから「データベースの設計者」の視点へと一段階レベルアップできます。

PostgreSQLのインデックスは、8KBという固定長の「ページ（ブロック）」の集合体です。このページの中に、データがどう詰め込まれているか。まずは、その基本構造を整理しておきましょう。

各ページは、大きく分けて3つのセクションで構成されています。

特に面白いのが、Item Dataは末尾から、Line Pointersは先頭から詰められるという点。この「お互いがぶつかるまで伸びていく」という設計は、メモリ効率を極限まで高めるための、古き良き職人技を感じさせます。

インデックス全体を俯瞰すると、3つの異なる役割を持つページたちが連携しています。

インデックスの「顔」です。常に最初のページ（ブロック番号0）に存在し、インデックスの現在のルートページがどこにあるか、あるいは削除されたページ（Free List）の先頭がどこかといった、インデックス全体の管理情報を保持しています。

ここは「道案内」の専門家です。キーの値と、次の階層（子ページ）へのポインタを持っています。この階層構造があるからこそ、数億行のデータからでも数回のI/Oで目的のデータに辿り着けるわけです。

ここが終着駅です。実際に「インデックスキー」と「TID（ヒープ上のレコード位置）」がペアで格納されています。ここが非常に重要なのは、インデックススキャンが成功するかどうかは、このリーフページをどれだけ効率的に読み込めるかにかかっているという点です。

現場でよく遭遇するパフォーマンス低下のサインとして、「インデックスの肥大化（Bloat）」があります。

なぜインデックスは肥大化するのか？それは、ページ内の「空き領域」の管理にあります。PostgreSQLのB-treeは、ページがいっぱいになると分割（Split）を起こしますが、既存の行が頻繁に更新（UPDATE）される環境では、削除されたレコードの領域が即座に再利用されないことがあります。

結果として、インデックスページがまばらになり、キャッシュヒット率が低下し、I/O負荷だけが増大する。これが「インデックスを貼っているのにクエリが遅い」という現象の典型的な正体です。

もし皆さんが「インデックスが効いていない」と感じたら、まずは以下のコマンドを叩いてみてください。

— pgstattupleを使ってインデックスの空き容量を可視化する
SELECT FROM pgstatindex(‘your_index_name’);

ここで `avg_leaf_density` が低い場合、それは「インデックスがスカスカで、無駄なI/Oを発生させている」ことを意味します。この場合、`REINDEX CONCURRENTLY` で構造を再構築するのが最も即効性のある処方箋です。

インデックスを単なる「検索用の魔法のツール」として使うのと、ページレイアウトという「データ構造」として理解して使うのでは、トラブルシューティングの精度が全く違います。

特に高負荷なシステムを運用していると、PostgreSQLが裏でどうやって8KBのブロックを操作し、どうやってポインタを繋いでいるかというイメージが、トラブルの兆候を察知するセンサーになります。

今日の内容は、PostgreSQLという深淵の、ほんの入口に過ぎません。皆さんの日常の運用の中で、「なぜここでインデックスが効率的に機能しないのか？」という疑問が湧いたとき、ぜひこのページレイアウトの構造を思い出してみてください。

それでは、また次回の深掘りでお会いしましょう。