pg_buffercacheモジュールは、共有バッファキャッシュで何が起きているかをリアルタイムに確認する方法を提供します。
このモジュールはレコード集合を返すpg_buffercache_pages C関数と、簡単に利用できるようにこの関数を隠蔽するpg_buffercacheビューを提供します。
どちらに対しても、潜在的なセキュリティ問題がありますので、デフォルトではPUBLICアクセスは取り除かれています。
pg_buffercacheビュービューによって公開されている列の定義を表F.14「pg_buffercacheの列」に示します。
表F.14 pg_buffercacheの列
| 名前 | 型 | 参照 | 説明 |
|---|---|---|---|
bufferid | integer | 1からshared_buffersまでの範囲で示されるID | |
relfilenode | oid | pg_class.relfilenode | リレーションのファイルノード番号 |
reltablespace | oid | pg_tablespace.oid | リレーションのテーブル空間OID |
reldatabase | oid | pg_database.oid | リレーションのデータベースOID |
relforknumber | smallint | リレーション内のフォーク番号。include/common/relpath.h参照 | |
relblocknumber | bigint | リレーション内のページ番号 | |
isdirty | boolean | ダーティページかどうか | |
usagecount | smallint | Clock-sweepアクセスカウント | |
pinning_backends | integer | このバッファをピン留めしているバックエンドの数 |
共有キャッシュ内の各バッファに対して、1行が存在します。
未使用のバッファは、bufferidを除き、すべてのフィールドがNULLになります。
共有システムカタログは、OIDがゼロのデータベースに属するものとして表示されます。
キャッシュはすべてのデータベースで共有されているため、現在のデータベースに属さないリレーションのページも表示されます。
これは、一部の行に対して一致する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 = pg_relation_filenode(c.oid) 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>