PostgreSQLの心臓部を覗く：ヒープページレイアウトという「職人芸」
PostgreSQLのパフォーマンスチューニングに深く入り込むと、最終的には必ず「ディスク上のデータは、一体どうやって整理されているのか？」という問いに突き当たります。
多くのエンジニアがインデックスの最適化やクエリプランの解析に時間を費やす中で、実はその基盤となる「ヒープページ（Heap Page）」の構造を深く理解している人は意外と少ない。でも、こここそがPostgreSQLのMVCC（多版同時実行制御）が魔法のように機能する場所であり、また、しばしばパフォーマンスを著しく低下させる「フラグメンテーション」の主戦場でもあるのです。
今日は、PostgreSQLのデータページ（デフォルト8KB）の内側を少し深掘りしてみましょう。
—
ページ内部の「住み分け」：なぜ下から上に詰めるのか
PostgreSQLのページレイアウトは、非常に論理的でありながら、ある種の「職人芸」を感じさせます。ページは主に以下の4つのセクションで構成されています。
1. ページヘッダ (Page Header): 先頭（下位アドレス）に配置。LSNやフラグ情報が詰まっています。
2. アイテムポインタ (Item Pointers / Line Pointers): ヘッダの直後に配置。各タプル（行データ）へのオフセットを保持する配列です。
3. 空き領域 (Free Space): ページの中央。ここが動的に変化します。
4. タプルデータ (Actual Tuple Data): 末尾（上位アドレス）から前方に向かって詰め込まれます。
ここで面白いのは、「アイテムポインタは前方から、タプルデータは後方から」向かってくるという点です。これにより、ページ内の空き領域を一元的に管理し、フラグメンテーションを最小限に抑える構造になっています。
アイテムポインタ：なぜ「間接参照」なのか
タプルに直接アクセスせず、わざわざ「アイテムポインタ（Line Pointer）」を介するのはなぜでしょう？
これはPostgreSQLのMVCC設計の要です。インデックス（B-tree等）は、このアイテムポインタのインデックス（`lp_off`）を指し示します。テーブルを更新（UPDATE）しても、タプルの物理的な場所が変わることはあっても、アイテムポインタの場所は（基本的には）変わりません。
この「間接参照」があるおかげで、インデックスを再構築することなく、ヒープ内のタプルを移動させたり、古いバージョンを掃除（VACUUM）したりできるわけです。非常にエレガントだと思いませんか？
パフォーマンストラブルシューティング：ヒープを汚すもの
現場でトラブルシューティングをしていると、「なぜかクエリが遅い」「IOPSが跳ね上がる」といった問題に遭遇します。その原因の多くは、ヒープページ内の「ゴミ（Dead Tuple）」にあります。
- HOT (Heap Only Tuple) 更新の失敗:
UPDATEの際、更新対象の列がインデックスに含まれていない場合、PostgreSQLはHOT更新を試みます。これにより、新しいタプルを同じページ内の空き領域に配置し、インデックス更新を回避します。しかし、ページが一杯だとHOT更新は失敗し、インデックスの再構築コストが発生します。
- ページ膨張 (Bloat):
頻繁な更新によって古いタプル（Dead Tuple）が残り続けると、ページ内の空き領域が断片化し、実質的なスキャン効率が落ちます。これは単にストレージを圧迫するだけでなく、`Seq Scan`の際のキャッシュヒット率を劇的に下げます。
私からのアドバイス：観測する勇気
ページ内部の状態を知るために、`pageinspect` 拡張は欠かせません。
— ページ内のアイテムポインタを確認する一例
SELECT FROM heap_page_items(get_raw_page(‘your_table’, 0));
このコマンドを叩いて、`lp_len`（データの長さ）や`t_infomask`（MVCCフラグ）を眺めてみてください。`t_xmin` や `t_xmax` がページの中でどのように散らばっているかを見るだけで、アプリケーションがどの程度「行儀よく」データベースを使っているかが手に取るようにわかります。
最後に：データベースは「物理」である
クラウドでマネージドサービスを使っていると、ついデータベースを「魔法の箱」のように感じてしまいがちです。しかし、PostgreSQLは結局のところ、8KBの箱をどう効率よく詰め込むかという、極めて物理的で泥臭い最適化の積み重ねです。
ページレイアウトを意識することは、単なる知識の習得ではありません。アプリケーションの設計段階で「このテーブルは更新頻度が高いから、タプルのサイズを絞ろう」とか「FILLFACTORを調整して、HOT更新を誘発させよう」といった、一段上の設計判断ができるようになるための第一歩です。
皆さんも、たまにはクエリの裏側、ディスク上のページという「小さな宇宙」に思いを馳せてみてはいかがでしょうか。そこには、数十年かけて洗練されてきたデータベースエンジニアたちの情熱が詰まっています。
コメント