【テクニカル・上級編】空き領域マップ（FSM） – PostgreSQL

PostgreSQLの「空き領域マップ（FSM）」：なぜPostgreSQLは、どこにデータを書き込むか即座に判断できるのか？

現場でPostgreSQLをいじり倒していると、ふと立ち止まって「なぜこのデータベースは、これほど巨大なテーブルに対しても、ページ単位の空き容量を瞬時に見つけ出せるのか？」と考えたことはないだろうか。

MVCCのアーキテクチャ上、更新のたびに新しいタプルを書き込む必要があるPostgreSQLにおいて、この「空き場所探し」はパフォーマンスのボトルネックになり得る。そこで登場するのが、`FSM (Free Space Map)` だ。

今回は、教科書的な説明はさらりと流して、この地味だが極めて重要なコンポーネントの深淵に触れていこう。

FSMの正体：階層的な「木」構造の必然性

FSMは、各ページがどれくらいの空き容量を持っているかを抽象化した「マップ」だ。だが、これを単なるビットマップやリストで管理しようとすると、テーブルが肥大化した瞬間にルックアップコストで死ぬ。

PostgreSQLのFSMは、階層的なツリー構造をしている。

リーフノード： 各ページ（8KB）の空き容量を、1バイト（0〜255の範囲）で表現する。実際には、空き容量を256分割した値が入っている。
中間ノード： 子ノードの最大値を持つ。

この構造の妙は、挿入（INSERT/UPDATE）時に「どのページならタプルが収まるか」を探索する際、ルートから辿ることで、空き容量の足りないページを瞬時に切り捨てられる点にある。テーブルが数テラバイトあっても、数回の比較で「書き込み可能なページ」に到達できる。この設計の美しさは、何度見ても溜息が出る。

パフォーマンストラブルシューティング：FSMが「嘘」をつく時

経験豊富なエンジニアなら、一度は直面したことがあるだろう。「明らかに空きがあるはずなのに、なぜかシーケンシャルスキャン並みに新しいページが割り当てられる」という現象だ。

ここで疑うべきは、FSMの「精度の低さ」だ。

FSMの各エントリは1バイトしかない。つまり、空き容量はあくまで「概算」だ。システムは、ある程度の余裕を持って空き容量を管理している。もし、FSM上の値と実際のページ内の空き容量に乖離が生じると、以下の問題が発生する。

1. 書き込みの非効率性： FSM上では空きがあるように見えても、実際には断片化（フラグメンテーション）が激しく、タプルが入らない。すると、PostgreSQLは無駄にページをスキャンした挙句、新しいページを拡張（Extend）することになる。
2. パフォーマンスの低下： `FSM_PAGES` の設定が小さすぎたり、あるいは大量の更新でFSMが追いつかなかったりすると、空き領域の再利用が滞る。

現場で役立つチェックポイント

もし「パフォーマンスが落ちている」「テーブルのサイズが異常に肥大化している」と感じたら、まずは以下を疑ってほしい。

`pg_freespace` 拡張を確認する：

`SELECT FROM pg_freespace(‘your_table’, 0);` を叩いてみてほしい。特定のページがFSMでどのように認識されているか、実測値と突き合わせることができる。

`max_fsm_pages` の幻影：

古いバージョンのPostgreSQLを知っている人ほど気にしがちだが、現在のPostgreSQLはFSMを自動管理している。だが、それでも負荷が激しい環境では、`AUTOVACUUM` のチューニングがFSMに与える影響は計り知れない。FSMを最新の状態に維持しているのは、他ならぬ `AUTOVACUUM` だからだ。

FSMとVacuumの切っても切れない関係

FSMは、Vacuumの恩恵を最大限に受ける仕組みだ。Vacuumは不要なタプルを掃除し、その領域を「ここ、空いたよ！」とFSMに通知する。

もし、Vacuumの頻度が低かったり、設定が甘かったりすると、FSMには「古い空き情報」しか残らない。結果として、PostgreSQLは既存の領域を再利用できず、どんどん後ろに新しいページを足していく。これが「謎のテーブル肥大化」の典型的な犯人だ。

最後に：データベースは「生き物」である

FSMという仕組みは、データベースが数テラバイトのデータとどう戦うかという、知恵の結晶だ。

単に `INSERT` が遅い、`UPDATE` が重いと嘆く前に、その裏でFSMという「地図」が正しく更新されているか、そしてその地図が現場の状況を正しく反映できているかを想像してほしい。

データベースエンジニアとしての腕の見せ所は、こうした「見えない構造」を頭の中で組み立て、ボトルネックの正体を見抜く瞬間にこそある。皆さんの環境でも、ぜひ一度 `pg_freespace` を覗いてみてほしい。そこには、あなたが知らないテーブルの「素顔」があるはずだ。