TIDスキャン：PostgreSQLの「裏口」を使いこなすための深淵なる知識
PostgreSQLを長く触っていると、インデックスを駆使したクエリチューニングや、プランナの挙動に一喜一憂する日々が続きますよね。しかし、時として「そんな手順を踏まなくても、この行がどこにあるか最初から知っている」という状況に直面することがあります。
そう、TID（Tuple Identifier）です。
今日は、PostgreSQLにおける最も高速、かつ最も特異なアクセス手法である「TIDスキャン」について、その深淵を少し覗いてみようと思います。
TIDスキャンとは何か：物理層へのダイレクトアクセス
TIDスキャンは、PostgreSQLのストレージエンジンにおける「物理的な番地指定」です。ご存知の通り、PostgreSQLの各テーブルはページ（デフォルト8KB）の集合体であり、その内部にはタプル（行）が並んでいます。
TIDは `(ブロック番号, オフセット番号)` というペアで構成されています。`ctid` システム列を参照すれば誰でも確認できるこの値は、そのタプルが物理的にどのページの、どの位置に鎮座しているかを指し示します。
TIDスキャンは、プランナが「インデックスをスキャンして条件を絞り込む」といった手順を一切スキップし、いきなり「そのブロックのそのオフセットへ飛べ」とディスク（あるいはバッファキャッシュ）に命令を下す手法です。これより速いアクセス手法は存在しません。
なぜこれが強力なのか、そしてなぜ危険なのか
この手法の最大の利点は、O(1)の計算量です。
インデックススキャンであれば、B-treeの深さに応じたLATCHの競合や、中間ノードの読み込みといったコストが発生します。しかしTIDスキャンにはそれがない。特定のIDが判明しているなら、論理的な検索をすべて無効化できるのです。
しかし、ここに大きな落とし穴があります。MVCC（多版同時実行制御）の罠です。
TIDは、あくまで「その時点での物理的な場所」に過ぎません。`VACUUM` が走ればタプルは移動する可能性がありますし、`UPDATE` が発生すれば、元のTIDは無効化され、新しいTIDを持つタプルが別の場所に生成されます。
もし、アプリケーション側で「前回のクエリで取得した `ctid` をキャッシュしておき、後でそれを使って再アクセスする」なんてコードを書いていたら、それは時限爆弾を抱えているのと同じです。VACUUMのタイミングによっては、全く関係のないレコードを更新したり、あるいは何も見つからなかったりと、予測不能な挙動を引き起こします。
パフォーマンストラブルシューティングの視点から
現場でTIDスキャンを積極的に活用すべきケースは非常に限定的ですが、それでも「緊急回避」や「超高頻度の単一行アクセス」において、TIDスキャンは神のような存在になります。
もし、パフォーマンス統計情報で `TidScan` が想定外の頻度で出現している場合、以下を疑ってください。
- アプリケーションレベルでのctidの永続化:
前述の通り、`ctid` をDB外部で保持しているケースです。これはアーキテクチャの敗北です。即座に主キーベースの検索に置き換えるべきです。
- 不適切な関数呼び出し:
特定のPL/pgSQL関数内で、動的に取得した `ctid` を使ってループ処理を行っているケース。これ自体は効率的ですが、トランザクションの分離レベルやVACUUMとの兼ね合いで、非常に繊細な設計が求められます。
熟練エンジニアへの提言：道具としてのTIDスキャン
私自身、TIDスキャンを「普段使い」することはまずありません。それはPostgreSQLが提供する安全で強力なインデックス機構を放棄する行為だからです。
しかし、データマイグレーションの最中、あるいは特定のバッチ処理で、膨大なテーブルの中から数百万件の特定の行だけを物理的な順序（物理レイアウト）を意識して処理したい時など、TIDスキャンは「最後の切り札」になります。
「ctidは、PostgreSQLの内部事情を垣間見るための窓である」
そう心に留めておいてください。物理構造を意識したチューニングができるエンジニアにとって、この「裏口」を理解していることは、トラブルシューティングの際の強力な武器になります。
次に `EXPLAIN` で `Tid Scan` の文字を見たとき、それが設計上の最適解なのか、それとも「たまたまそこに居合わせた」だけの現象なのか。一度立ち止まって考えてみてください。データベースの深層心理が、そこには見えているはずです。
コメント