[pgsql-jp: 27741] Re: 見積り表領域と

KAWAI,Takanori GCD00051 @ nifty.ne.jp
2002年 10月 25日 (金) 17:32:47 JST


川合孝典です。

----- Original Message -----
From: <sugita @ sra.co.jp>
To: <pgsql-jp @ ml.postgresql.jp>
Sent: Friday, October 25, 2002 3:38 PM
Subject: [pgsql-jp: 27739] Re: 見積り表領域と


>   杉田です。
(中略)
> ;;; ただ、それに基づいて187ではなく186で計算すると。
> ;;; ブロック数は537.63 => 538, 使用ディスク量: 4,407,296
> ;;; となり、さらに実測値と違ってきます。
> ;;;
> ;;; これはNULLビットマスクが常に入るという計算にしているからでは
> ;;; ないかと思われます。
>
>   Revision: 1.13 の資料に NULL ビットマスクを全行に必要とコメントしたの
で、、、
>
> ;;;                     そこで、その分を引いて、これをレコードの大きさを
> ;;; 40として計算すると
>
>   引かないで、最悪の場合で見積もってもいいんじゃないでしょうか。
私の説明がまずかたようで。
実際の計算では、それで構わないと思います。
ただここでは「切り捨てて計算すると実測値との違いが大きいじゃない」
てなことになると、いけないかなということで。
Revision: 1.13でもNULLビットマスクが32項目単位ということが書かれて
いたので、そのことも含めてということで。

#実際に自分でやってみて、3つのINTEGERのフィールドに
#(1)全部NULL (2) 1項目だけ値 (3) 2項目だけ値 (4) 全部に値
#として見たところ、ファイルの大きさが(1) < (2) < (3) = (4) と
#なったので、悩んだりしてたのでオマケとしてつけました。

(中略)
> ;;; ただ客先からは「管理上のディスク使用量を予測したい」という
> ;;; ことなので、pg_classのrelpagesとreltuplesを見て、1レコードあたりの
> ;;; 平均値を求めて、出すようなものも用意する必要があるかなぁと
> ;;; 今は考えています。
>
>   ソートワークファイル、インデックス作成ワークファイルなども考えて、予測し
たい
> とは思いますが、、、
実際にはもちろん、そこまで含めて考える必要があると思うのですが、
vacuum analyzeがある程度の頻度で行われれば、目安として
テーブルファイルやインデックスファイルの大きさはわかるんじゃないかと
思っていたんですが、いかがでしょう?

===================================================
川合 孝典 (Hippo2000)
   DBI日本語メーリングリスト管理人、Kansai.pm所属
   kwitknr @ cpan.org GCD00051 @ nifty.ne.jp
   http://member.nifty.ne.jp/hippo2000、http://www.hippo2000.info/
perldocの日本語化ならperldocjp:もちろん参加者募集中!
  http://sourceforge.jp/projects/perldocjp
===================================================




pgsql-jp メーリングリストの案内