各テーブルには、ほとんどのデータが格納される主要なヒープディスクファイルがあります。 テーブルに広い値を持つ可能性のある列がある場合、テーブルに関連付けられたTOASTファイルもあり、これはメインテーブルに収まりきらない広すぎる値を格納するために使用されます（65.2を参照してください）。 TOASTテーブルに有効なインデックスが存在する場合、そのインデックスが1つ存在します。 また、ベーステーブルに関連付けられたインデックスがある場合もあります。 各テーブルとインデックスは、別々のディスクファイルに格納されます。 ファイルが1ギガバイトを超える場合は、複数のファイルが格納されることもあります。 これらのファイルの命名規則については65.1で説明します。

ディスク容量の監視は、次の3つの方法で行えます。 表 9.100にあるSQL関数を使用する方法、oid2nameモジュールを使用する方法、およびシステムカタログを手動で調べる方法です。 SQL関数を使用する方法が、一般的に一番簡単な方法です。 この節の残りの部分では、システムカタログを調べる方法を示します。

最近バキュームされたか、あるいは分析されたデータベースでpsqlを使用すると、任意のテーブルのディスク使用状況を調べるための問い合わせを発行できます。

SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';

 pg_relation_filepath | relpages
----------------------+----------
 base/16384/16806     |       60
(1 row)

1ページは通常8キロバイトです。 （relpagesはVACUUMとANALYZE、さらにCREATE INDEXといったいくつかのDDLによってのみ更新されることに注意してください。） もしテーブルのディスクファイルを直接調べるときは、ファイルのパス名称に注目して下さい。

TOASTテーブルが使用している容量を表示するには、以下のような問い合わせを使用します。

SELECT relname, relpages
FROM pg_class,
     (SELECT reltoastrelid
      FROM pg_class
      WHERE relname = 'customer') AS ss
WHERE oid = ss.reltoastrelid OR
      oid = (SELECT indexrelid
             FROM pg_index
             WHERE indrelid = ss.reltoastrelid)
ORDER BY relname;

       relname        | relpages
----------------------+----------
 pg_toast_16806       |        0
 pg_toast_16806_index |        1

インデックスサイズも簡単に表示できます。

SELECT c2.relname, c2.relpages
FROM pg_class c, pg_class c2, pg_index i
WHERE c.relname = 'customer' AND
      c.oid = i.indrelid AND
      c2.oid = i.indexrelid
ORDER BY c2.relname;

      relname      | relpages
-------------------+----------
 customer_id_index |       26

この情報を使用すると、最大のテーブルとインデックスを簡単に見つけられます。

SELECT relname, relpages
FROM pg_class
ORDER BY relpages DESC;

       relname        | relpages
----------------------+----------
 bigtable             |     3290
 customer             |     3144

データベース管理者の最も重要なディスク監視作業は、ディスクが容量不足になっていないことを確認することです。 データディスクが容量不足になったなった場合、データの破損は発生しませんが、有用な活動が行われなくなる可能性があります。 WALファイルを保持しているディスクがいっぱいになると、データベースサーバがパニックし、それに続くシャットダウンが発生する可能性があります。

他のデータを削除しても、ディスクに空き容量を用意できない場合、 テーブル空間を使用することによって、データベースファイルのいくつかを他のファイルシステムに移動できます。 詳細は 22.6を参照してください。

システムでユーザ単位のディスククォータをサポートしている場合、当然ながらデータベースもサーバを実行するユーザに割り当てられたクォータに従います。 クォータを超えた場合、ディスク容量が完全になくなった時と同じ悪影響が発生します。