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

隠れた英雄「Visibility Map」が、PostgreSQLのクエリを劇的に加速させる仕組み

PostgreSQLを長く触っていると、ふと「なぜこのクエリはこれほど速いのか？」と立ち止まる瞬間があるはずです。特に、膨大なテーブルに対してインデックスオンリースキャン（Index Only Scan）が走った時など、そのレスポンスには魔法のような効率を感じる。

その「魔法」の正体の一つが、Visibility Map（可視性マップ）です。

今日は、PostgreSQLのコアアーキテクチャの中でも、特に地味ながらも強力なこのコンポーネントの深淵に触れていこうと思います。

Visibility Mapとは何か？

端的に言えば、Visibility Mapは「このページ内のタプルは、現在生きているすべてのトランザクションから見て可視（Visible）か？」という情報を保持する、各テーブルに紐付いたビットマップです。

通常、PostgreSQLは行が可視かどうかを判断するために、各タプルのヘッダにある`xmin`や`xmax`を確認し、さらにCLOG（Commit Log）を参照してトランザクションの状態を確認します。これには少なからずコストがかかる。

しかし、Visibility Mapに「このページの全タプルは可視である」というビットが立っていれば、わざわざタプルの中身（ヒープ）にアクセスして可視性を確認する必要がなくなるのです。

なぜインデックスオンリースキャンが速いのか

皆さんがよく知る「Index Only Scan」の裏側では、このVisibility Mapが主役として働いています。

1. インデックスから対象行のポインタ（TID）を取得する。
2. そのTIDが指すページのVisibility Mapを確認する。
3. ビットが立っていれば、「ヒープアクセス不要」と判断し、インデックス内の情報だけでクエリを完了させる。

これが、Visibility Mapが存在しない世界だとどうなるか。全ての行に対して「本当にこのデータは今見えて良いものか？」を確認するために、物理的なヒープページを読み込む「Heap Fetches」が発生します。I/Oコストが跳ね上がるのは明白ですね。

パフォーマンストラブルシューティングの勘所

Visibility Mapは非常に優秀ですが、運用においてはいくつか注意点があります。特に私が現場で遭遇する「なぜか遅い」というケースの多くは、Visibility Mapが活用されていないことが原因です。

Vacuumの頻度とVisibility Mapの関係

Visibility Mapのビットを立てるのは、主に`VACUUM`の仕事です。もし`autovacuum`が適切に動いておらず、テーブルが更新され続けていると、Visibility Mapはいつまでも「クリーン」な状態になれません。`pg_stat_user_tables`の`n_dead_tup`や`last_autovacuum`を注視するのは基本中の基本です。

頻繁な更新による「ビットの剥がれ」

UPDATEが頻発するテーブルでは、Visibility Mapのビットはすぐにクリアされます。ビットが立っていないページは、たとえほとんどのタプルが可視であっても、PostgreSQLは安全のためにヒープを確認せざるを得ません。この「ビットの更新頻度」と「クエリ性能」のトレードオフを意識することが、チューニングの第一歩です。

バッファキャッシュの汚染

非常に巨大なテーブルでIndex Only Scanを多用すると、ヒープへのアクセスは減りますが、インデックス自体がメモリに乗らないサイズだと、結局インデックスの読み込みでI/Oが枯渇します。Visibility Mapは「ヒープアクセスを減らす」ための最適化であって、物理的なストレージの限界を打ち破る魔法ではないことを忘れてはいけません。

最後に：エンジニアとしての視点

PostgreSQLのアーキテクチャの面白いところは、こうした「少しずつ積み上げられた妥協と最適化」が、絶妙なバランスで成り立っている点です。

Visibility Mapは、マルチバージョン並行制御（MVCC）というPostgreSQLの最も強力な武器が抱える「可視性確認のコスト」に対する、非常にエレガントな回答の一つです。

皆さんのDBで「Index Only Scan」が効いていないクエリがあれば、ぜひ`EXPLAIN ANALYZE`を叩いてみてください。「Heap Fetches」の数値がもし0でなければ、そこにはまだ改善の余地――Visibility Mapを有効活用するためのチューニングの種が眠っています。

アーキテクチャの深層を知ることは、単に設定値を弄る以上の面白さがあります。これからも、この「データベースの鼓動」を深く理解し、最高のパフォーマンスを引き出していきましょう。