pg_buffercacheモジュールは、実時間で共有バッファキャッシュで何が起きているかを確認する方法を提供します。
このモジュールはレコード集合を返すpg_buffercache_pages C関数と、簡便に利用できるようにこの関数を包み隠すpg_buffercacheビューを提供します。
デフォルトでは、潜在的なセキュリティ問題がありますので、どちらに対してもPUBLICアクセスは取り除かれています。
ビューにより公開される列の定義を以下に示します。
表 F-17. pg_buffercacheの列
| 名前 | 型 | 参照 | 説明 |
|---|---|---|---|
| bufferid | integer | ID。1からshared_buffersまでの範囲 | |
| relfilenode | oid | pg_class.relfilenode | リレーションのRelfilenode |
| reltablespace | oid | pg_tablespace.oid | リレーションのテーブル空間のOID |
| reldatabase | oid | pg_database.oid | リレーションのデータベースのOID |
| relblocknumber | bigint | リレーション内のページ番号 | |
| isdirty | boolean | ダーティページかどうか | |
| usagecount | smallint | ページのLRU数 |
共有キャッシュ内の各バッファに対して1行が存在します。 未使用のバッファはbufferidを除きすべてのフィールドはNULLになります。 共有システムカタログはゼロデータベースに属するものとして表示されます。
キャッシュはすべてのデータベースで共有されているため、通常現在のデータベースに属さないリレーションによるページが存在します。 これは、一部の行に対して一致するpg_classの結合行が存在しない、最悪間違った結合をしてしまう可能性があることを意味します。 pg_classに対して結合しようとする場合、現在のデータベースのOIDまたは0と等しいreldatabaseを持つ行に限定して結合することは良い考えです。
pg_buffercacheビューにアクセスがあると、内部バッファマネージャはビューが表示するすべてのバッファ状態をコピーするために十分な期間ロックを取得します。 これにより、一貫した結果集合が生成されること、また、必要以上に長く通常のバッファ操作がブロックされないことが保証されます。 それにも関わらず、このビューが頻繁に読み取られると、データベース性能に多少影響が発生する可能性があります。
regression=# SELECT c.relname, count(*) AS buffers
FROM pg_buffercache b INNER JOIN pg_class c
ON b.relfilenode = c.relfilenode AND
b.reldatabase IN (0, (SELECT oid FROM pg_database
WHERE datname = current_database()))
GROUP BY c.relname
ORDER BY 2 DESC LIMIT 10;
relname | buffers
---------------------------------+---------
tenk2 | 345
tenk1 | 141
pg_proc | 46
pg_class | 45
pg_attribute | 43
pg_class_relname_nsp_index | 30
pg_proc_proname_args_nsp_index | 28
pg_attribute_relid_attnam_index | 26
pg_depend | 22
pg_depend_reference_index | 20
(10 rows)
Mark Kirkwood <markir@paradise.net.nz>
設計補助: Neil Conway <neilc@samurai.com>
デバッグにおける忠告: Tom Lane <tgl@sss.pgh.pa.us>