PostgreSQLの「禁じ手」か、それとも「奥の手」か。TIDスキャンという名の最短経路
PostgreSQLを長く触っていると、誰しも一度はクエリの遅延という壁にぶつかります。複雑なJOIN、重い集計、そして「どうしてそこまでインデックスを無視するんだ」と叫びたくなるようなプランナの気まぐれ。
そんな時、我々エンジニアが最後に辿り着く、あるいは「あえて使わないでおこう」と封印するアクセスパスがあります。それがTIDスキャン（TID Scan）です。
今日は、PostgreSQLの内部構造を深く理解しているあなたに向けて、この「物理的な最短距離」について少し掘り下げてみましょう。
—
TIDスキャンとは何か：物理層への直通エレベーター
ご存知の通り、PostgreSQLの各レコードには、そのページ内の位置を示す物理的な識別子、`ctid`（Tuple Identifier）が付与されています。TIDスキャンは、インデックスを辿ることも、シーケンシャルスキャンで全ページをなめることもなく、`ctid`をキーにして、特定のページ内の特定のタプルを直接メモリ（あるいはディスク）から叩き出す手法です。
計算量は $O(1)$。論理的には、PostgreSQLで実行可能な最も高速なデータアクセスです。
しかし、なぜ我々はこれを滅多に使わないのでしょうか。
なぜ「ctid」は主キーになり得ないのか
多くの若手エンジニアが、「IDを保存しておいて、後でそれで引けば爆速じゃん！」と閃く瞬間があります。しかし、熟練のあなたなら既にお分かりの通り、`ctid`は極めて不安定な値です。
- VACUUMと再配置: `VACUUM FULL`や`CLUSTER`コマンドが走れば、データはページを跨いで移動します。当然、`ctid`も変わります。
- UPDATEの性質: PostgreSQLのMVCCモデルにおいて、UPDATEは事実上の「DELETE + INSERT」です。更新された行は別の場所に書き込まれるため、新しい`ctid`が割り振られます。
つまり、`ctid`をアプリケーション層で永続化するのは、砂の上に城を築くようなものです。それでもなお、TIDスキャンがプロの現場で輝くケースが存在します。
TIDスキャンが真価を発揮する「ニッチな現場」
私が過去にTIDスキャンを実務で採用したのは、数億行規模のログテーブルをバッチ処理で更新する際でした。
1. 二次インデックスの重複排除: 非常に大きな範囲をスキャンし、重複するキーを見つけ出す際、一度のクエリで全件取得するのではなく、まず`ctid`のリストをメモリに保持する。
2. 細切れの更新: その後、取得した`ctid`を使って個別にアクセスし、行を書き換える。
これにより、インデックスの過度な更新によるオーバーヘッドを抑え、トランザクションの粒度を制御することができました。これは、「データの一貫性」と「物理レイアウトの制御」を天秤にかけた、ある種の職人芸的なチューニングです。
パフォーマンストラブルシューティングの視点
もし、あなたがクエリプランナーに`TidScan`を見つけたら、まずは以下の点を疑うべきです。
- 無意識のハードコーディング: アプリケーション側のコードで、動的に`ctid`を生成してクエリを投げていないか？（これは将来の悲劇の種です）
- 不適切なキャッシュ機構: 何らかのライブラリやフレームワークが、DBの物理構造を過信したキャッシュ戦略を採っていないか？
- 「とりあえず速いから」の悪用: 特定のタプルを頻繁に更新するために、物理位置を固定しようとする設計は、必ず将来のメンテナンスを破壊します。
最後に：エンジニアとしての矜持
TIDスキャンは、PostgreSQLの深淵を覗くための鍵です。しかし、この鍵を使うことは、データベースの抽象化レイヤーを意図的に踏み越えることを意味します。
「便利だから」という理由で多用するのではなく、「なぜこれが必要なのか」というアーキテクチャ上の必然性がある時にだけ、そっと引き出しから取り出す。そんな距離感が、熟練したエンジニアには似合っているのではないでしょうか。
あなたのシステムでTIDスキャンを見かけた時、それが「計算された最適化」なのか、それとも「設計の破綻」なのか。ぜひ、その目で確かめてみてください。
さて、次はどの深淵を覗いてみましょうか。
コメント