【テクニカル・上級編】可視性マップ（Visibility Map） – PostgreSQL

「見えないもの」を可視化する：PostgreSQLにおけるVisibility Mapの深淵

データベースのパフォーマンスチューニングに長く携わっていると、ふと「PostgreSQLは、なぜこれほどまでに効率的に、かつ安全にデータを読み出せるのか」という根源的な問いに立ち返ることがあります。

MVCC（多版同時実行制御）はPostgreSQLの心臓部ですが、その代償として「各タプルがどのトランザクションから見えるか」を判定するために、いちいちヒープページにアクセスして `xmin` や `xmax` を確認する必要があります。これがいかにコストの高い処理か、現場でクエリの遅延に悩まされた経験がある方なら骨身に染みているはずです。

そこで登場するのが Visibility Map（可視性マップ） です。今回は、この控えめながらも強力なコンポーネントが、いかにしてインデックスのみスキャン（Index Only Scan）を支え、高負荷時のI/Oを救っているのかを深掘りしてみましょう。

—

Visibility Mapの正体と静かなる役割

Visibility Mapは、各ヒープページの状態をビットで管理する小さなファイル（`_vm`接尾辞が付くもの）です。各ビットは、そのページ内のすべてのタプルが「すべての現行トランザクションから可視であるか（all-visible）」を示しています。

ここが重要です。もしビットが立っていれば、PostgreSQLはヒープページにアクセスして各タプルのトランザクションID（XID）を確認する必要はありません。「このページは全員から見えている」と確信できるため、ヒープを見に行くという最も重いプロセスをショートカットできるのです。

これが、Index Only Scanの爆速の源泉です。本来ならヒープへのランダムアクセスが発生するはずの場面で、メモリ上のマップを確認するだけで完結する。この「I/Oの回避」こそが、大規模データベースにおいて天と地ほどの差を生みます。

パフォーマンストラブルの「隠れた犯人」を追う

現場でよくある相談の一つに、「インデックスは適切に貼ってあるのに、Index Only Scanが効かない」というものがあります。

多くのエンジニアはここで「統計情報が古いのでは？」と疑いますが、Visibility Mapの観点から見ると、別の景色が見えてきます。

更新頻度とVACUUMの怠慢:

Visibility Mapは、主にVACUUMプロセスがヒープをスキャンする際に更新されます。もし更新が激しいテーブルで `autovacuum` が追いついていないと、ビットがセットされる機会が失われます。結果として、ページは「all-visible」と見なされず、インデックスがあってもヒープへのアクセスが強制されることになります。

「ヒントビット」との関係性:

PostgreSQLはヒープページへのアクセス時に「ヒントビット（Hint Bits）」を立ててトランザクションの状態を記録しますが、これとVisibility Mapは共犯関係にあります。VACUUMはページ内のヒントビットを読み取り、すべてが可視であると判断すれば、Visibility Mapのビットをオンにします。つまり、VACUUMが走れないほど高負荷な環境では、Visibility Mapはいつまでも「未完成」のままです。

チューニングの現場から：どう立ち回るべきか

では、実務においてこのアーキテクチャをどう活かすべきか。

1. `vacuum_cost_limit` の再考:
大規模なテーブルでは、autovacuumがVisibility Mapを更新しきる前に次の更新が来てしまうことがあります。I/O帯域に余裕があるなら、autovacuumのコスト設定を緩和し、Visibility Mapの更新を加速させることは、インデックスのみスキャンのヒット率を劇的に向上させる特効薬になります。
2. モニタリングの視点:
`pg_visibility_map` などの拡張機能を使って、どの程度のページが実際に可視化されているかを可視化するのも一手です。「なぜ遅いのか」を推測で語るのではなく、ビットの状態を追いかけることで、ボトルネックが「物理的なI/O」なのか「論理的な構造の不備」なのかを切り分けることができます。

最後に

Visibility Mapは、PostgreSQLがMVCCという複雑な仕組みの上で、いかに「現実的な速度」を維持しようと足掻いているかを示す、非常に人間味のある（あるいは泥臭い）設計です。

「データベースが遅い」と感じたとき、その背後でヒープページが必死に可視性を証明しようと奔走している姿を想像してみてください。Visibility Mapを正しく理解し、VACUUMの挙動を制御することは、DBエンジニアにとっての「調律」そのものです。

派手なクエリチューニングも良いですが、こうした低レイヤーの構造に思いを馳せることが、システムの安定稼働への近道だと私は信じています。

皆さんのデータベースのVisibility Mapは、今、どれくらいクリーンに保たれているでしょうか？