【実務・中級編】可視性マップ（Visibility Map） – PostgreSQL

やあ。データベースのチューニングに頭を悩ませる日々、お疲れ様。
今日は、多くのエンジニアが意外と見落としがちな、でも「ここを知っていると一目置かれる」PostgreSQLの縁の下の力持ち、可視性マップ（Visibility Map）について話をしようと思う。

「インデックスオンリースキャン（Index Only Scan）が速いのは知ってるけど、なぜ速いのか？」と聞かれたとき、自信を持って答えられるかな？その答えの鍵を握るのが、この可視性マップなんだ。

—

PostgreSQLはMVCC（多版同時実行制御）という仕組みを採用しているよね。あるトランザクションから見て「このデータは見えるのか、見えないのか」を判定するために、データページの中にある `xmin` や `xmax` を毎回確認しにいく必要がある。

でもさ、考えてみてほしい。テーブルのほとんどのデータが、もうどのトランザクションからも修正されることなく確定している状態だったら？毎回わざわざページを読み込んで、タプル一つ一つを確認しにいくのは、どう考えても無駄だよね。

そこで登場するのが可視性マップ（Visibility Map）だ。
これは、テーブルの各ページに対して「このページ内のタプルは、全トランザクションから見て可視（＝これ以上MVCCチェックの必要なし）ですよ」という情報を、ビット単位で保持している地図のようなものなんだ。

PostgreSQLがクエリを実行するとき、もしインデックスだけでデータが完結しそうなら「インデックスオンリースキャン」を試みる。でも、インデックスの情報だけだと「そのデータが現在も有効なのか（削除されていないか）」までは確証が持てない。

通常なら、ここでテーブルのデータページまで読みに行く「ヒープアクセス」が発生する。これがボトルネックになりがちなんだけど、ここで可視性マップの出番だ。

1. インデックスから該当行を見つける。
2. 可視性マップを確認し、そのページが「全可視（All-Visible）」だとわかれば……。
3. ヒープアクセスをスキップ！

これで、重いディスクI/Oを大幅に削減できるわけだ。これが、インデックスオンリースキャンが爆速な理由の正体だよ。

理屈だけじゃなく、実際に動いているところを確認するのがエンジニアの醍醐味だよね。`pg_visibility` 拡張を使うと、このマップの状態を覗き見ることができるんだ。

— まず拡張をインストール（superuser権限が必要）
CREATE EXTENSION pg_visibility;

— 特定のテーブルの可視性マップ情報を確認
SELECT FROM pg_visibility_map(‘my_table’);

ここで `all_visible` が `true` になっているページは、まさにインデックスオンリースキャンが「ヒープを見に行かずに済む」場所だ。

もし「インデックスオンリースキャンが効いていないな」と感じたら、`VACUUM` が足りていない可能性を疑ってみてほしい。`VACUUM` は単にゴミ掃除をするだけじゃなく、この可視性マップを更新する重要な役割も担っているからね。

可視性マップは超優秀なんだけど、一つだけ覚えておいてほしいことがある。
「VACUUMが走らないと、マップは更新されない」ということだ。

データの更新頻度が高いテーブルで、もし `autovacuum` の設定が甘いと、可視性マップはいつまで経っても「全可視」にならない。結果、インデックスオンリースキャンが使われず、パフォーマンスがズルズルと落ちていく……というのは、現場でよくある悲劇の一つなんだ。

インデックスオンリースキャンが効いていない？ → `EXPLAIN ANALYZE` を見て、ヒープアクセスが発生していないかチェック。
VACUUMの頻度は適切か？ → テーブルの更新頻度に合わせて、`autovacuum_vacuum_scale_factor` を絞り込んでいくのも一つの手だよ。

可視性マップは、PostgreSQLが「どのデータが安定しているか」を記憶しておくためのショートカットだ。この仕組みを知っているだけで、パフォーマンスチューニングの引き出しが一つ増えるし、何より「なぜDBがこう動くのか」という解像度がグッと上がるはずだよ。

明日からのDB運用で、ぜひこの「裏方」の働きに目を向けてみてほしい。きっと、今まで見えなかったボトルネックが見えてくるはずだから。

それじゃ、また現場で会おう。何か困ったことがあったら、いつでも聞きに来てくれよな。