【テクニカル・上級編】システムカタログ(pg_catalog)の概要 – PostgreSQL

PostgreSQLの深淵を覗く：`pg_catalog`と`information_schema`の静かなる共生

PostgreSQLを長く触っていると、ふとした瞬間に「このデータベースは、自分自身のことをどうやって記憶しているのか？」という根源的な問いにぶつかることがあります。

普段は`psql`で`\d`を打ったり、GUIクライアントでテーブル一覧を眺めたりするだけで満足してしまいがちですが、その裏側で何が起きているのか。今日は、PostgreSQLのメタデータ管理の心臓部である`pg_catalog`と、その「お作法」である`information_schema`について、少し深い話をしようと思います。

`pg_catalog`という「生の真実」

PostgreSQLにおいて、`pg_catalog`は単なるカタログではありません。それはデータベースのアイデンティティそのものです。

テーブル、カラム、インデックス、関数、型、そして権限に至るまで。データベースが「今、どのような状態にあるか」というメタデータは、すべてこのスキーマ内のシステムテーブルに書き込まれています。

エンジニアとして興味深いのは、このシステムテーブル群が、ユーザーが作成する通常のテーブルと全く同じデータ構造、同じトランザクション制御下で管理されているという点です。つまり、`pg_catalog`への書き込みもMVCC（多版同時実行制御）の対象であり、PostgreSQLというシステムが自分自身を「PostgreSQLのテーブル」として実装しているという、美しい再帰構造が見て取れます。

なぜ `information_schema` が存在するのか

一方で、初心者向けのマニュアルでよく目にするのが`information_schema`です。これを見て、「`pg_catalog`があるのに、なぜわざわざ別のスキーマが？」と疑問に思う方もいるでしょう。

端的に言えば、`information_schema`は「互換性と抽象化」のレイヤーです。

SQL標準（ISO/IEC 9075）によって定義されたこのスキーマは、データベース製品が変わっても同じクエリでメタデータを取得できるように設計されています。一方で、`pg_catalog`はPostgreSQL独自の内部実装に深く依存しています。

`information_schema`: SQL標準準拠。移植性が高く、汎用的なツール開発に向いている。
`pg_catalog`: PostgreSQL固有。PostgreSQL特有の機能（TOAST、拡張インデックスの種類、トリガーの詳細設定など）をフル活用する際に必須となる。

熟練エンジニアの視点で言えば、アドホックな調査や複雑なメタデータ操作を行う際は、迷わず`pg_catalog`を叩くべきです。`information_schema`はビューの集合体であり、複雑なJOINが必要になることも多いため、大規模なカタログを探索する際はパフォーマンス上の足かせになることがあるからです。

現場で直面するパフォーマンストラブル：メタデータロックの罠

さて、ここからが少し込み入った話です。

運用中、突然クエリが滞留し始めたことはありませんか？その犯人が、実はメタデータへの頻繁なアクセスであることは珍しくありません。

`pg_catalog`のテーブルは通常のテーブルと同様にロックされます。例えば、極めて頻繁に`ALTER TABLE`を行うバッチ処理や、カタログに対して重たいスキャンをかける監視エージェントが走っていると、システムカタログの行に対するロック競合（`AccessShareLock` vs `AccessExclusiveLock`）が発生します。

特に注意が必要なのは、「メタデータへの同時アクセス集中」です。
数千個のテーブルを持つ巨大なデータベースで、カタログを安易に全スキャンするようなクエリを投げると、システム全体がスローダウンします。

Tips: カタログを叩く際は、必ず`oid`や`relname`でインデックスが効くようにクエリを絞り込むこと。
Tips: `pg_stat_user_tables`などの統計情報ビューを活用し、カタログの実テーブル（`pg_class`など）に直接触る機会を最小限に抑えること。

最後に：データベースとの対話

`pg_catalog`を直接覗くことは、データベースという巨大な生き物の「脳内」を覗くようなものです。

「なぜこのクエリはプランナが意図したインデックスを選んでくれないのか？」、「なぜこの権限設定が反映されないのか？」といったトラブルに直面したとき、`pg_catalog`は嘘をつかない唯一の回答者になってくれます。

PostgreSQLをただの箱として扱うのではなく、そのメタデータ構造までを理解することで、設計の質は格段に上がります。みなさんも、たまには標準ツールに頼らず、`SELECT FROM pg_class`から始まるデータベースとの対話を楽しんでみてはいかがでしょうか。

そこには、PostgreSQLの設計思想という名の、美しい論理が広がっていますから。