【実務・中級編】 タプルヘッダーのInfomask – PostgreSQL

こんにちは！今日も元気にPostgreSQLの深淵を覗きに来てくれたかな？

僕のブログを読んでくれている君なら、PostgreSQLのパフォーマンスチューニングや内部挙動の理解が、日々の運用や開発でどれだけ重要か、もう肌で感じているんじゃないかな。表面的なSQLの最適化も大事だけど、時には一歩踏み込んで、PostgreSQLが「どう動いているのか」を知ることで、これまで見えなかった世界が広がるんだ。

さて、今日はちょっとマニアックな話になるけど、PostgreSQLの性能を語る上で、絶対に避けて通れない、それでいて普段は意識されることの少ない「タプルヘッダーのInfomask」について、じっくり解説していこうと思う。

「Infomask？何それ美味しいの？」って思った君もいるかもしれないね。大丈夫、これを読み終える頃には、君のPostgreSQLに対する理解度がグッと深まっているはずだ。

タプルの状態を司る「Infomask」とは？

まず、PostgreSQLにおける「タプル」って何だったか、覚えているかな？そう、テーブルの「行」のことだよね。ディスク上に保存されるデータの実体、と言ってもいい。

このタプルには、実際にユーザーが入力したデータ（カラムの値）だけじゃなくて、PostgreSQLがMVCC（多版型同時実行制御）を実現するために必要な様々な「メタデータ」が付随しているんだ。これを「タプルヘッダー」と呼ぶ。

タプルヘッダーには、例えばこんな情報が含まれているよ。

  • `t_xmin`: そのタプルを作成したトランザクションのID
  • `t_xmax`: そのタプルを削除・更新したトランザクションのID
  • `t_cid`: コマンドID（同じトランザクション内でのコマンドの順序）
  • `t_ctid`: そのタプルの更新後の新しいタプルへのポインタ（更新チェイン）

これらはMVCCの可視性判定に不可欠な情報なんだけど、実はこの他にも、もっと細かい「タプルの状態」を示すフラグの集合体が潜んでいるんだ。それが今日の本題、「Infomask（`t_infomask` と `t_infomask2`）」ってわけさ。

イメージとしては、車のダッシュボードにある「エンジンチェックランプ」とか「シートベルト警告灯」みたいなものだと思ってくれると分かりやすいかもしれない。タプル自身が「俺、今こんな状態だよ！」って教えてくれるステータスランプの集まりなんだ。

なぜInfomaskが必要なの？

じゃあ、なんでわざわざそんなフラグが必要なんだろう？主な理由は次の2つだ。

1. 高速な可視性判定
2. VACUUMなどのメンテナンス処理の効率化

PostgreSQLはトランザクションIDを使ってタプルの可視性を判断するんだけど、`t_xmin` や `t_xmax` で示されるトランザクションが「コミット済み」なのか「アボート済み」なのか、あるいは「まだ実行中」なのか、という情報は、本来なら別途 `pg_clog` (Commit Log) と呼ばれる領域を見に行かないと分からない。

でも、いちいち `pg_clog` を見に行くのは、それなりにコストがかかる処理なんだ。そこでInfomaskの出番！もしタプルヘッダーに「この `t_xmin` はコミット済みだよ！」というフラグが立っていれば、`pg_clog` を参照する手間が省けて、可視性判定が劇的に高速化されるんだ。

これは、特にOLTP系のワークロードで大量のタプルをスキャンする際や、VACUUMが不要なタプルを特定する際に、ものすごく効いてくるポイントなんだよ。

Infomaskの具体的なフラグを見てみよう

さて、このInfomaskには、具体的にどんな情報が詰まっているのか、いくつか主要なフラグを見てみよう。これらのフラグは、PostgreSQLのソースコード、特に `src/include/access/htup_details.h` で定義されているよ。

// src/include/access/htup_details.h (抜粋)

/

  • HeapTupleHeaderData is defined in htup_details.h, not htup.h, because
  • we don’t want to include that much stuff in access/htup.h
  • NOTE: For historical reasons, the items here are not ordered to minimize
  • padding, but rather according to their age and perceived importance.

/
typedef struct HeapTupleHeaderData
{
union
{
HeapTupleFields t_heap;
DatumTupleFields t_datum;
} t_choice;

TransactionId t_xmin; / inserting xact ID /
TransactionId t_xmax; / deleting or locking xact ID /

union
{
CommandId t_cid; / inserting or deleting command ID /
TransactionId t_xvac; / for vacuum, when t_xmax is a vacuum /
} t_field3;

ItemPointerData t_ctid; / current TID of following update (or self) /

uint16 t_infomask2; / number of attributes, various flags /
uint16 t_infomask; / various flag bits (see below) /
uint8 t_hoff; / offset to user data /

/ IMPORTANT: t_bits field must be at the end of HeapTupleHeaderData /
bits8 t_bits[FLEXIBLE_ARRAY_MEMBER]; / bitmap of NULLs /
} HeapTupleHeaderData;

/

  • t_infomask bits
  • NOTE: only the first 8 bits of t_infomask are stored in the commit log
  • and thus are guaranteed to be stable across crashes. The remaining bits
  • may be lost if the server crashes.

/
define HEAP_XMIN_COMMITTED 0x0001 / t_xmin committed /
define HEAP_XMIN_ABORTED 0x0002 / t_xmin aborted /
define HEAP_XMAX_COMMITTED 0x0004 / t_xmax committed /
define HEAP_XMAX_ABORTED 0x0008 / t_xmax aborted /
define HEAP_XMAX_LOCK_ONLY 0x0010 / xmax is a “locking” transaction /
define HEAP_XMAX_KEYSHR_LOCK 0x0020 / xmax holds a KEY SHARE lock /
define HEAP_XMAX_EXCL_LOCK 0x0040 / xmax holds an EXCLUSIVE lock /
define HEAP_XMAX_IS_MULTI 0x0080 / t_xmax is a MultiXactId /
define HEAP_UPDATED 0x0100 / this is an UPDATEed tuple /
define HEAP_HOT_UPDATED 0x0200 / this is a HOT-updated tuple /
define HEAP_IS_LOCKED 0x0400 / this tuple is locked (for RECOVERY) /
define HEAP_COMPRESSED 0x0800 / this tuple has compressed data /

/

  • t_infomask2 bits
  • NOTE: t_infomask2 is not stored in the commit log, and thus is not
  • guaranteed to be stable across crashes.

/
define HEAP_NATTS_MASK 0x07FF / 11 bits for number of attributes /
define HEAP_HASOID 0x8000 / has OID field /
define HEAP_MOVED_OFF 0x4000 / moved to another block in same rel /
define HEAP_MOVED_OFF_END 0x2000 / moved to another block in same rel, at end /
define HEAP_MOVED (HEAP_MOVED_OFF | HEAP_MOVED_OFF_END)

たくさんあるけど、特に覚えておきたいフラグはこれらだね。

  • `HEAP_XMIN_COMMITTED`: `t_xmin` で示されるトランザクションがコミット済みであることを示す。
  • `HEAP_XMIN_ABORTED`: `t_xmin` で示されるトランザクションがアボート済みであることを示す。
  • これらが立っていれば、`pg_clog` を見に行く必要なし！すぐに可視性判定ができる。
  • `HEAP_XMAX_COMMITTED`: `t_xmax` で示されるトランザクションがコミット済みであることを示す。
  • `HEAP_XMAX_ABORTED`: `t_xmax` で示されるトランザクションがアボート済みであることを示す。
  • これも上記と同様、`pg_clog` 参照をスキップできる。
  • `HEAP_XMAX_LOCK_ONLY`: `t_xmax` が行ロック（`SELECT FOR UPDATE`/`SHARE` など）によって設定されたもので、タプルの削除や更新ではないことを示す。
  • `HEAP_UPDATED`: このタプルが `UPDATE` によって生成された新しいバージョンのタプルであることを示す。これによって、古いタプルと新しいタプルが鎖状につながっていることが分かる。
  • `HEAP_HOT_UPDATED`: これが特に重要！このタプルが「HOT更新（Heap-Only Tuple update）」されたタプルであることを示す。
  • HOT更新とは、テーブルの同じページ内で新しいタプルが作成され、インデックスを更新する必要がない効率的な更新のことだ。これについては後で詳しく話すよ。

`t_infomask` の上位ビットや `t_infomask2` には、その他にもタプルの属性数（`HEAP_NATTS_MASK`）やOIDの有無（`HEAP_HASOID`）、タプルが他のブロックに移動したかどうか（`HEAP_MOVED`）など、様々な情報が詰まっているんだ。

実務での活用例と考慮点

「ふむふむ、フラグがあるのは分かった。でも、僕らが直接このフラグをSQLで指定するわけじゃないよね？」

その通り！君が普段書くSQLで直接Infomaskを操作することはない。でも、このInfomaskがどのように使われているかを知ることで、PostgreSQLの挙動を深く理解し、パフォーマンス問題に直面したときに、より的確な原因究明や対策を立てられるようになるんだ。

1. VACUUMの効率化とHOT更新

Infomaskが最も輝く場面の一つが、VACUUM処理の効率化だ。

PostgreSQLのMVCCでは、`UPDATE` や `DELETE` されても、古いバージョンのタプルはすぐには削除されない。これらの「不要になったタプル（Dead Tuple）」を回収するのがVACUUMの役割だよね。

VACUUMは、各タプルの `t_xmin` や `t_xmax` が示すトランザクションの状態（コミット済みか、アボート済みか）を確認して、Dead Tupleかどうかを判断する。ここで `HEAP_XMIN_COMMITTED` や `HEAP_XMAX_COMMITTED` といったフラグが立っていれば、`pg_clog` を参照する手間が省け、VACUUM処理を高速化できるんだ。

さらに、`HEAP_HOT_UPDATED` フラグは、HOT更新の成否に深く関わってくる。

  • HOT更新とは？
  • `UPDATE` 文が実行された際、更新後の新しいタプルが、更新前の古いタプルと同じデータページ内に収まる場合、PostgreSQLはインデックスを更新せずに、新しいタプルへのポインタ（`t_ctid`）だけを更新する。これがHOT更新だ。
  • HOT更新が成功すると、インデックスへの変更がないため、インデックスを更新するコストや、後でインデックスからDead Tupleを削除するコスト（VACUUM FULL）が大幅に削減される。これは、特に更新頻度の高いテーブルにとって、非常に大きなパフォーマンス改善につながるんだ。

このHOT更新が可能かどうかは、Infomaskやタプルのサイズ、ページ内の空き容量など、いくつかの条件に依存する。もしテーブルの更新が多いのに `pg_stat_user_tables` の `n_tup_hot_update` が低い値であれば、HOT更新が十分に活用できていない可能性がある。その原因を深掘りする際に、Infomaskが設定されるロジックを知っていると、適切なチューニングのヒントになるんだ。

例えば、VACUUMが古いタプルの `t_xmax` に `HEAP_XMAX_COMMITTED` フラグをセットすることで、そのタプルがDead Tupleであることを効率的にマークし、HOT更新のチェインを健全に保つ手助けをする。

2. 可視性判定の高速化

繰り返しになるけど、`HEAP_XMIN_COMMITTED` や `HEAP_XMAX_COMMITTED` といったフラグが立っていることで、通常の `SELECT` クエリ実行時のタプルの可視性判定が高速化される。

PostgreSQLは、タプルを読み込むたびに `HeapTupleSatisfiesMVCC()` といった内部関数で可視性をチェックするんだけど、この関数内でInfomaskが参照され、`pg_clog` へのアクセスをスキップできるかどうかが判断されるんだ。多くのタプルをスキャンするような重いクエリでは、この積み重ねが無視できないパフォーマンス差を生むことがある。

3. ロックの識別のヒント

`HEAP_XMAX_LOCK_ONLY`, `HEAP_XMAX_KEYSHR_LOCK`, `HEAP_XMAX_EXCL_LOCK` といったフラグは、`t_xmax` に設定されたトランザクションIDが、タプルの削除や更新ではなく、行ロックのためだけに使われていることを示す。

これによって、ロックの状態を効率的に判断できるため、デッドロック検出やロック競合の解決など、内部的なロック管理のオーバーヘッドを軽減するのに役立っているんだ。

まとめ

今日はPostgreSQLのタプルヘッダーに潜む「Infomask」について深掘りしてみたけど、どうだったかな？

Infomaskは、普段は意識することのない、まさに「縁の下の力持ち」だ。MVCCの可視性判定を高速化したり、VACUUMやHOT更新といった重要なメンテナンス処理の効率を向上させたりと、PostgreSQLの安定した性能を支える上で欠かせない役割を担っている。

直接SQLで触ることはなくても、君がPostgreSQLのパフォーマンスチューニングや問題解決に取り組む上で、「なぜこのテーブルはVACUUMが重いんだろう？」「なぜHOT更新が効かないんだろう？」といった疑問にぶつかった時、このInfomaskの存在と思い出してみてほしい。内部構造を知っているからこそ得られる「なぜ？」の答えが、きっと君を次のレベルへと引き上げてくれるはずだ。

これで君も、また一歩PostgreSQLマスターに近づいたね！
それでは、また次回の記事で会おう！

スポンサーリンク

コメント

タイトルとURLをコピーしました