[pgsql-jp: 25047] Re: HDDサイズ

[Naofumi Kondoh]

ソフト工房の近藤です。

sugita ＠ sra.co.jp wrote:

詳細な資料ありがとうございます。参考になります。

.....snip....

>     フィールドが NULL 値かどうかを判断するNULL ビットマスクによって、NULL 値の
>     場合には値を格納する領域はタプル内に取られません。従って、ビットフラグが存
>     在し、すべてのフィールドについてタプル内に格納領域が必要として見積もりをす
>     るならば、実測値を下回る可能性は少なくなります。

なるほど。こういう仕掛けになっているんですね。

NULL の場合はデーター領域が節約できるのですね。
私は、NULL 判定が面倒なので、特に支障がないか
ぎり、NOT NULL DEFAULT 0 などとする方式なので
すが、NULL が多い場合は DEFAULT にしないで、
NULL 判定をした方がデータースペースの節約にな
りそうですね。

古い版ですが、Informix ONLINE 4.2 だと INTEGER 
型の場合は特定の値を NULL だとする方式で、他に
ビットはとらないけど、ESQL/C で読み込むと、NULL
が integer(４バイト)の範囲内なのでちょっぴりや
やこしいです。 

....snip...

>     約 +10% の誤差があります。この誤差は、インデックスファイル内のインデックペー
>     ジが 100% 埋まることがないために発生します。

PostgreSQL の Btree index  は、reindex か DROP/CREATE
INDEX をしないと、インデックスサイズは増えていくと
思いました。  キーの偏りで中身が少くなっても Btree
node の自動再編成はしないはずですね。更新頻度が高い
場合は、インデックス領域をかなり余分に見込んでおかな
いといけなのではないでしょうか。


>     decimal                 圧縮 (サイズは値の桁数に依存)
>     numeric                 圧縮 (同上)

やっぱり圧縮しているんですね。
4 bit に十進数１桁が入る方式でしょうか？。
# COBOL の PACK DECIMAL のような。


>     character(n)            圧縮
>     character varying(n)    圧縮
>     text                    圧縮

text 型も圧縮しているとは知りませんでした。
# 石井さんの本をちゃんと読んでいないのが
# バレバレ (^^;;
どんなアルゴリズムですか。オーバーへッドは
どのくらいなんでしょう。

..... snip ...

>     データベースのサイズは以下の要因により動的に変化します。
> 
>         1) 更新の頻度 (テーブルファイルとインデックスファイルに影響)
>         2) ソートを必要とするクエリーのワークファイル

ソートや JOIN 用のワークエリアの見積りが一番難しい
ですね。何か妙案はありませんでしょうか。

>         3) テンポラリテーブルの使用の有無
>         4) WAL ファイルサイズ
>         5) REINDEX のワークファイル
>         6) バックアップ領域などの付随的なワーク領域
> 
>     従って、静的なサイズの見積もりに加え、運用シナリオを作成し、実験を行ってディ
>     スク使用量を見積もります。特に 1) は PostgreSQL の追記型という特徴を反映し
>     た影響を受けるので、VACUUM の適用と合わせて運用設計を行います。

やはり、運用を想定して実験し、運用状態をモニター
しながら適宜対策するというのが結論でしょうか。

... snip ...

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
 (株)ソフト工房   近藤直文        Email:  nkon ＠ shonan.ne.jp 
  《 PostgreSQL+PHPソースコードジェネレーターデモＧＰＬ版 》
           http://www.SOFTKOUBOU.co.jp/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/