[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 メーリングリストの案内