【実務・中級編】サブトランザクションログ – PostgreSQL

PostgreSQLの「サブトランザクション」と仲良くなるための基礎知識

やあ。最近、PostgreSQLのログを眺めていて「あれ、なんでこんなにサブトランザクションが多発してるんだ？」なんて悩んだことはないかな？

実務でPostgreSQLを触っていると、フレームワーク（Railsの`transaction do … end`とか、PythonのSQLAlchemyとか）が裏で当たり前のように使っている「サブトランザクション」に出くわすことがある。でも、いざ「これって内部でどう動いてるの？」と聞かれると、意外と答えに詰まってしまうものだよね。

今日は、PostgreSQLのコアアーキテクチャの中でも、ちょっと玄人好みな「サブトランザクション（Subtransaction）」の仕組みについて、現場の視点から紐解いていこうと思う。

—

サブトランザクションってそもそも何？

一言で言えば、「トランザクションの中にある、小さな独立したトランザクション」のことだ。

普通、データベースのトランザクションは「全部成功か、全部失敗か」という単位だけど、サブトランザクションを使えば「全体は失敗させたくないけど、この処理だけは失敗してもリカバリできるようにしておきたい」という贅沢な要求を叶えられる。

具体的には、`SAVEPOINT`というSQLコマンドがこれにあたる。

BEGIN;
INSERT INTO users (name) VALUES (‘Alice’);

SAVEPOINT my_savepoint; — ここがサブトランザクションの開始

INSERT INTO logs (message) VALUES (‘Alice created’);
— 万が一ここでエラーが起きても、SAVEPOINTまでロールバックすれば
— AliceのINSERTは無事残る、という仕組みだね。

RELEASE SAVEPOINT my_savepoint;
COMMIT;

内部の「サブトランザクションログ（Subtrans）」の正体

さて、ここからが本題だ。PostgreSQLのエンジンは、この親子関係をどうやって管理しているんだろう？

PostgreSQLには、`pg_subtrans`というディレクトリがある。これが「サブトランザクションログ」を格納している場所だ。

仕組みのキモ：親子関係の木構造

PostgreSQLは、メモリ上の「CLOG（トランザクションの状態を記録するログ）」だけでは、ネストされたトランザクションの階層を追いきれない。そこで、サブトランザクションごとに「親は誰か？」という情報を`pg_subtrans`に書き込んでいるんだ。

親トランザクションがコミットされると、その子であるサブトランザクションの状態も自動的に「コミット済み」として扱われる。
逆に、親が死ねば子も死ぬ。この親子関係を高速に辿るために、PostgreSQLはトランザクションID（XID）の親子情報をサブトランザクションログにキャッシュしているわけだ。

注意！実務でハマる「パフォーマンスの罠」

ここまで聞くと「便利じゃん、どんどん使おう！」と思うかもしれない。でも、ちょっと待ってほしい。現場のエンジニアとして、これだけは覚えておいてほしいことがある。

「サブトランザクションの多用は、パフォーマンスを著しく低下させる」

なぜか？理由は主に2つある。

1. ロックのオーバーヘッド: サブトランザクションを生成するたびに、メモリ上の管理コストが増える。
2. サブトランザクションログの肥大化: 大量のサブトランザクションが同時並行で走ると、`pg_subtrans`への書き込みがボトルネックになり、PostgreSQL全体のパフォーマンスがガクンと落ちるんだ。

特に、ORMが自動的に発行する`SAVEPOINT`がループの中で動いているようなケースは要注意だよ。気づかないうちに数千個のサブトランザクションが生成されて、クエリが異様に遅くなる……なんていうのは、DBチューニングあるあるの筆頭だ。

どう付き合っていくべきか

結論として、僕のアドバイスはこうだ。

ORMの挙動を疑う: もしパフォーマンスが落ちているなら、まずログを見て「SAVEPOINT」が大量に発行されていないか確認しよう。
ビジネスロジックで制御する: 可能な限り、SQLレベルのサブトランザクションに頼らず、アプリケーション側で「この処理は失敗してもいい」というロジックを組むのが理想だ。
どうしても必要な時だけ使う: もちろん、複雑なバッチ処理などでどうしても必要なときはある。そのときは「今、サブトランザクションが走っている」という意識をしっかり持って設計してほしい。

—

最後に

PostgreSQLのアーキテクチャは、本当に洗練されているけれど、その裏側にはこうした「整合性を保つための工夫」が隠されている。

「なんとなく動く」から「なぜ動いているか分かる」へステップアップすると、トラブルシューティングのスピードが劇的に変わるはずだ。もし、君のプロジェクトでクエリの遅延に悩んだら、この記事を思い出して`pg_subtrans`の存在を疑ってみてくれ。

また何か気になることがあったら、いつでも聞いてくれよ。現場からは以上だ！