2012年6月15日

[pgsql-jp: 41138] Re:■質問■PostgresSQLのディスク使用量の増える仕組みについて

笠原と申します。

> そこで、あらかじめ想定するデータ件数+ΑのダミーレコードをINSERTしてデ
> ータファイルを拡張しておき、それらすべてのダミーレコードをDELETEします。
> TRUNCATEではありません。
> そして、念のためVACUUMを実行しておきます。
>
> そうすると、データファイルが必要な分だけ大きくなります。

> VACUUMによりその領域すべてが空きとなります。
> したがって、本当のレコードを挿入するときに、データファイルを拡張せずにすみます。
細かい話ですが、すべてのレコードをDELETEされた後にVACUUMをした場合、
テーブルのブロックが8kB(最小)まで切り詰められてしまいます。
(VACUUMはファイル末尾が空であれば、切り詰めるため)

なので、ファイルの末端のレコード(投入したダミーレコードの最後)は
残しておく必要があります。

# ファイル拡張の他にも、永安さんのコメントにあるとおりバッファ溢れなども
考慮しないといけません。とすると、データ量を加味してshared_buffer の
調整も必要になります。

--
笠原 辰仁


> -----Original Message-----
> From: pgsql-jp-bounces@xxxxx
> [mailto:pgsql-jp-bounces@xxxxx] On Behalf Of MauMau
> Sent: Thursday, June 14, 2012 7:57 PM
> To: PostgreSQL Japanese Mailing List
> Subject: [pgsql-jp: 41135] Re: ■質問■PostgresSQLのディスク使用量の増
> える仕組みについて
>
> 渡辺さん
>
>
> MauMauです。
>
> 解決策として、次のようなことをおためしいただくのはどうでしょう?
>
> 組み込み用途ということから、最大データ量が定まっているのではないかと思
> います。
>
> そこで、あらかじめ想定するデータ件数+ΑのダミーレコードをINSERTしてデ
> ータファイルを拡張しておき、
> それらすべてのダミーレコードをDELETEします。
> TRUNCATEではありません。
> そして、念のためVACUUMを実行しておきます。
>
> そうすると、データファイルが必要な分だけ大きくなります。
> VACUUMによりその領域すべてが空きとなります。
> したがって、本当のレコードを挿入するときに、データファイルを拡張せずに
> すみます。
>
>
> 8.3で注意することは、VACUUMの表示にしたがって、
> max_fsm_relationsとmax_fsm_pagesを設定することです。
> 8.4以降なら、FSMの設定は不要でです。
>
>
> 以上です。
>

投稿者 xml-rpc : 2012年6月15日 14:45
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/110834
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。