2010年10月29日

[pgsql-jp: 40480] Re:INSERTの処理時間に関しまして

お世話になっております、友利です。
早速のご回答ありがとうございます。

>データのトランケートには、TRUNCATE のSQLを使っていますか?

TRUNCATEのSQLを使用しています。

>関連するテーブルやインデックスの定義、

>具体的なデータの投入手順を示してもらえると、具体的なコメントが
>つくかもしれません。

データ投入手順としまして、
対象テーブルをトランケートし、90万件のデータから、
15万件を取得しINSERTしています。
15万件のINSERTを繰り返し行っています。
INSERT対象テーブルは、主キーが2項目でINDEXは
主キーのみです。

>VACUUM FULLではインデックスは掃除されないため
>一応確認してみてください。

以下のSQLで確認してみました。
 select pg_size_pretty(pg_relation_size('【INDEX名】'))
 結果:768M
となっており、増大していないと思われます。
この確認方法でよろしいでしょうか。

また、関数「pgstatindex」を使用してみましたところ、
「does not exist」となり使用不可でした。
こちらのインストール方法をご存知でしたら、ご教授いただきたいのですが。

宜しくお願い致します。

-----Original Message-----
From: pgsql-jp-bounces@xxxxx [mailto:pgsql-jp-bounces@xxxxx] On Behalf Of Itagaki Takahiro
Sent: Thursday, October 28, 2010 3:54 PM
To: PostgreSQL Japanese Mailing List
Subject: [pgsql-jp: 40475] Re: INSERTの処理時間に関しまして

2010/10/28 <munekatsu.tomori@xxxxx>:
> Postgresql8.3.9を使用して90万件のデータをINSERTしています。
> この処理は、一度データをトランケートし90万件を再度INSERTしています。
> 処理時間が当初2時間程度でしたが、4ヵ月後では6時間近くかかっています。
> 別の環境を作成し、現象の再現を試みましたが、再現せず調査が手詰まりの状態です。

データのトランケートには、TRUNCATE のSQLを使っていますか?
それならば、DB 的には、毎回ほぼ初期状態に戻っているはずです。
もし時間が変わったなら、例えばファイルシステムレベルの
断片化が影響しているかもしれません。

DELETE で消していたり、外部キー (REFERENCE) があると、
また話が変わってきます。(DELETE + VACUUM FULL もダメです!)
差し支えのない範囲で、関連するテーブルやインデックスの定義、
具体的なデータの投入手順を示してもらえると、具体的なコメントが
つくかもしれません。

> テーブル内の不要領域が増大していることが原因とも思いましたが、
> 処理時間が6時間かかっている環境はVACUUM FULLを実行していますので、
> 可能性は薄いと思っています。

INSERT 対象のテーブルを TRUNCATE しているのであれば、あまり関係
無いかもしれませんが、VACUUM FULLではインデックスは掃除されないため
一応確認してみてください。「VACUUM FULL していれば安心」という
思い込みは、むしろ危険です。
# 9.0 の VACUUM FULL ならば(必要性はさておき)「安心」なのですが。

--
Itagaki Takahiro


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




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