[pgsql-jp: 27011] Re: 表領域の計算方法

[sugita ＠ sra.co.jp]

  杉田です。

From: Naofumi Kondoh <nkon ＠ shonan.ne.jp>
Date: Tue, 13 Aug 2002 16:24:17 +0900

;;; システムカタログではなく、contrib/oid2name を改良
;;; した単独のツールの方がよいのでは。
...
;;; PostgreSQL には、表領域を事前に確保しておくという
;;; 考え方がないので、表領域のサイズが必要な都度実行す
;;; る単体ツールの方が適切だと思います。

  7.3devel に contrib/dbsize というのがあります。

    ====  README.dbsize  ===========================================
    This module contains two functions that report the size of a given
    database or relation.  E.g.,

    SELECT database_size('template1');
    SELECT relation_size('pg_class');

    These functions report the actual file system space.  Thus, users can
    avoid digging through the details of the database directories.

    Copy this directory to contrib/dbsize in your PostgreSQL source tree.
    Then just run make; make install.  Finally, load the functions into any
    database using dbsize.sql.

    When computing the size of a table, it does not include TOAST or index
    disk space.

;;; 表領域は計算である程度見積もりできると思いますが、
;;; $PGDATA の下には、SORT や MERGE JOIN 等々で使用する
;;; WORK FILE も作成されます。これらはどういう SQL が
;;; どういうタイミングで発行されるかによるので HDD 容量の
;;; 予測が難しいです。皆さんは、どのように見積もられている
;;; でしょうか？。

  ソートファイルについては、簡単な実験からは、最悪で、

    ソートされるレコードサイズ * レコード数 * 1.1

でよさそうです。ソートがどの SQL で要求されるかとレコード数については、そのシ
ステムで使う典型的な SQL を実際に近いデータで explain して予測値を決めるとか。

;;; $PGDATA のパーティションの使用状況をモニターして、
;;; 早めに対策するといった運用で対処するしかないでしょうか。

  運用時間の経過と共に、データ量や質が変わって行くので、予測しても実際のモニター
で予測と違って来ていないかを監視する必要があると思います。


Kenji Sugita