PostgreSQLの「心臓」を覗き見る：pg_classと向き合うということ
PostgreSQLを長年触っていると、ふとした瞬間に「このデータベースは結局、どうやってテーブルやインデックスを識別しているのか？」という根源的な疑問に突き当たることがあります。
もちろん、`\d`コマンドを叩けば構造は分かります。しかし、大規模なシステムで「なぜ今、このクエリが遅延しているのか」「なぜカタログアクセスの競合（Lock contention）が起きているのか」を突き詰めていくと、必ず最後に辿り着く場所がある。それが `pg_class` です。
今日は、PostgreSQLのメタデータ管理の要であり、最も「深淵に近い」システムカタログである `pg_class` について、エンジニアの視点で深掘りしてみましょう。
—
pg_classは単なる「テーブル一覧」ではない
初心者向けの解説では「テーブルやインデックスのリスト」と説明されますが、実務レベルでは「PostgreSQLにおけるあらゆるリレーションの『DNA』が格納された場所」と捉えるべきです。
`pg_class` には、単なる名前やOIDだけでなく、以下のようなパフォーマンスに直結する情報が刻まれています。
- relpages / reltuples: クエリプランナが統計情報として使用する「概算行数」と「ページ数」。
- relfilenode: 物理的なファイルパスを特定するための識別子。
- relam: インデックスであれば、それがB-treeなのか、GiSTなのかを決定するアクセスメソッドのOID。
- relfrozenxid: トランザクションIDの周回問題（Vacuumの重要指標）を判定するための値。
ここが面白いのは、PostgreSQL自身がこのカタログを「ただのテーブル」として管理している点です。つまり、`pg_class` もまた `pg_class` 自身によって定義されているという、再帰的な美しさがあるわけです。
—
パフォーマンストラブルシューティング：カタログ競合の罠
熟練エンジニアが頭を抱えるのが、高負荷時における「システムカタログへのアクセスの競合」です。
例えば、頻繁に `CREATE TEMPORARY TABLE` や `DROP TABLE` を繰り返すようなアプリケーションを運用していると、`pg_class` への更新が集中します。すると、カタログに対する `RowExclusiveLock` がボトルネックとなり、データベース全体のパフォーマンスがガクンと落ちることがあります。
トラブルシューティングの勘所
もし「特定のテーブルにアクセスしているわけではないのに、システム全体が重い」と感じたら、以下の観点で `pg_stat_activity` を覗いてみてください。
1. ロックの競合: `pg_locks` で `pg_class` に対する `AccessExclusiveLock` や `RowExclusiveLock` が滞留していないか確認する。
2. autovacuumの状況: カタログテーブル自体もVacuumの対象です。大規模なスキーマ変更を行った直後、`pg_class` の統計情報が更新されず、プランナが迷走するケースは意外と多いのです。
3. カタログキャッシュの枯渇: `shared_buffers` だけでなく、カタログキャッシュが溢れて物理I/Oが発生していないか。
—
内部アーキテクチャ：なぜ統計情報は「嘘」をつくのか
`pg_class` の中の `reltuples` を見て、「おや、行数が全然違うぞ？」と思ったことはありませんか？
そう、`pg_class` の統計情報は「概算」です。特に `VACUUM` や `ANALYZE` が適切に走っていない環境では、この値は事実から大きく乖離します。プランナは、この `pg_class` の数値を元に、Nested LoopにするかHash Joinにするかを決めています。
ここでの教訓はシンプルです。「データベースの判断を信頼しすぎるな」ということ。
もしクエリが遅いなら、まず `EXPLAIN ANALYZE` を実行し、`actual rows` と `pg_class` に記録されている（プランナが見ている）推定行数を見比べてください。この乖離こそが、パフォーマンスチューニングにおける「宝の地図」です。
—
最後に：カタログと仲良くする
`pg_class` を深く理解するということは、PostgreSQLというエンジンの「脳内構造」を理解することと同義です。
カタログをいじることは禁忌ですが、それを覗き込み、何が起きているのかを推論する能力は、トラブルシューティングの現場では間違いなく最強の武器になります。
「なぜこのクエリはハッシュ結合を選んだのか？」
「なぜこのインデックスは無視されたのか？」
その答えは、常に `pg_class` の中に眠っています。たまには `SELECT FROM pg_class WHERE relname = ‘あなたの悩みの種’` を実行して、そのテーブルがPostgreSQLからどう見えているのか、対話してみてはいかがでしょうか。
エンジニアリングの深淵は、意外とすぐ足元にあるものです。それでは、また。
コメント