[pgsql-jp: 27115] Re: システムカタロ

Naofumi Kondoh nkon @ shonan.ne.jp
2002年 8月 22日 (木) 19:19:04 JST


ソフト工房の近藤です。

GSP05271 @ nifty.com wrote:
> 佐々木と申します。
> 早速の回答有難う御座います。
> 
> 
>>[pgsql-jp: 27100]で紹介した URL のスクリプトは、
>>DB定義関係の情報を取得するものです。
> 
> 
>  上記URLで紹介したURLのスクリプトに関する質問です。
> 
>   下記のコマンドを実行してsampleテーブルを作成しましたが、
>  上記のURLのスクリプトshow.dd.shを実行した結果
>  timestamp型の長さが19バイトになっていました。
...略....

スクリプトを見ていただきたいのですが、timestamp などの
長さは、case で、リテラル勝手に埋め込んでいるものです。
ご自分の用途にあった値にするなり、不要なら、長さを
省略してください。

ここでは、画面入力幅・表示幅を示すものとして、長さを
表示しています。

timestamp 型だと、'YYYY-MM-DD HH:MM:SS'  と想定して、
19 という数字を埋め込んでいるだけです。

# まあ、text 型は表示長のとりようがないのですっぱり
# あきらめるしかないですね。

佐々木さんは、ディスクスペースの計算をされたいんです
よね。でしたら、表示長でなく、各型の内部形式での
バイト数を調べる必要があります。text 型など圧縮される
ものもあるので、過去ログなどを参考にされるといいと
思います。

----------------
私の場合は、小規模(せいぜい数GB〜10GB位)のデーター部
のDBしか扱っていないので、よほど厳密な用途でない限り、
細かい計算はしていません。

単純にたっぷりとパーティションを割り当てて、運用監視
しながら、対策をとるというやり方です。

用途によるので一概に言えないのですが、インデックスの追加
やら、エンドユーザーコンピューティングの推奨により、
思わぬ大きな SORT が動くとか、予想しにくいことが多いの
と、HDD が安価になったので、事前に細かい計算するコスト
よりも、大きい HDD を購入した方が安価だろうという考え
です。

あくまでも、ケースバイケースですので、厳密な計算が事前
に必要な場合もあります。

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
 (株)ソフト工房   近藤直文        Email:  nkon @ shonan.ne.jp
http://www.SOFTKOUBOU.co.jp/      http://www.shonan.ne.jp/~nkon/
2002-08-27(火)19:00-21:30 第5回 JPUG 業務アプリ分科会 勉強会
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/





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