【テクニカル・上級編】 xmin / xmax – PostgreSQL

PostgreSQLを触っていて、ふと「MVCC（多版同時実行制御）の裏側で何が起きているのか」を突き詰めたくなったことはありませんか？

テーブルをスキャンする際、なぜあんなにも高速に「今の自分に見えるはずのデータ」だけを抽出できるのか。その答えは、すべてのタプル（行）のヘッダーに静かに刻まれている、`xmin` と `xmax` という二つの数字にあります。

今日は、ドキュメントの隅っこに追いやられがちなこのメタデータが、実はDBのパフォーマンスやトラブルシューティングの要であるという話をしましょう。

—

PostgreSQLにおいて、データは「上書き」されません。`UPDATE` を発行すれば、古いタプルはそのまま残り、新しいタプルが別の場所に挿入されます。この「どのタプルがどのトランザクションから見えるか」を管理しているのが、`xmin` と `xmax` です。

シンプルですよね。でも、ここからが面白いんです。

例えば、ある行を更新したとき、元のタプルの `xmax` は更新したXIDで埋まり、新しく生成されたタプルの `xmin` にもそのXIDが刻まれます。つまり、この二つのフィールドを見るだけで、PostgreSQLは「この行は誰が作り、誰が殺したのか」という系譜を一瞬で把握できるわけです。

ここで一つ、高度なエンジニアなら気にかけるべきポイントがあります。`xmin` と `xmax` の判定は、毎回 `pg_xact`（旧 `pg_clog`）を参照してトランザクションのコミット状況を確認する必要があります。

もし毎回のクエリで全行に対してこれを行うと、I/Oが枯渇してシステムは即座に悲鳴を上げます。そこで登場するのが「ヒントビット（Hint Bits）」です。

一度判定したトランザクションの状態を、データページ上のタプルヘッダーに「フラグ」として書き込むことで、次回の参照コストを劇的に下げる。この「計算結果を汚す（書き込む）」という割り切りこそが、PostgreSQLの設計思想の美しさだと私は思っています。

`xmin` と `xmax` の仕組みを知ると、なぜ「放置された古いタプル（Dead Tuples）」がパフォーマンスを殺すのかが腹落ちするはずです。

VACUUMの重要性: `xmax` が設定されたタプルは、その後、どのトランザクションからも参照されなくなった瞬間に初めて「ゴミ」となります。しかし、PostgreSQLはそれを自動的には掃除しません。VACUUMが走らない限り、インデックススキャンは無駄なDead Tuplesを拾い続け、クエリプランは劣化し続けます。
Long-running Transactionの罠: 非常に長いトランザクションが一本でも動いていると、そのトランザクションが開始された時点の `xmin` より古いタプルは、物理的に消すことができません。結果、`VACUUM` をどれだけ回してもテーブルが肥大化（Bloat）し続ける。これが、大規模システムで深夜のバッチ処理が朝のピーク時に悪影響を及ぼす典型的なパターンです。

トラブルシューティングの際、私はよく `pageinspect` 拡張を使います。

— 特定のページ内のタプルヘッダーを確認する
SELECT t_xmin, t_xmax, t_ctid FROM heap_page_items(get_raw_page(‘your_table’, 0));

もし、`xmax` に古いXIDが残ったままの行が大量に見つかるようなら、それはVACUUMの設定不足か、あるいはどこかで「ゾンビトランザクション」が生き残っている証拠です。

「なぜクエリが遅いのか？」と悩んだとき、インデックスやSQLの書き方だけでなく、ぜひこの `xmin/xmax` の世界に潜ってみてください。データベースが裏側でどれほど必死に整合性を保とうとしているか、その足跡が見えるようになると、チューニングの解像度が一段階変わりますよ。

—

データベースという巨大な機械を扱う以上、私たちは単にSQLを書く人ではなく、その内部で「時間」がどう流れているかを制御する設計者でなければなりません。

皆さんのDBが、今日も健やかにトランザクションをさばいていることを願っています。それでは、また別の深いトピックでお会いしましょう。