[pgsql-jp: 26423] Re: 大量データの更新

[Hashimoto, Masaru]

橋本です。

> ソフト工房の近藤です。
> 
返信ありがとうございます。

> 
> > 件数が少ないと割合早く終わります。
> > ですが、更新されていない件数はあまり多くないので、
> > 毎回結構な量を更新する必要があります。
> > 
> > それでも、少しでも件数を少なくするために
> > 差分データにするようにお願いしたのですが、
> > データを吐き出すシステムのほうが対応していないので
> > 実現できませんでした。
> 
> 差分データーでないということは、更新の必要がない
> データーも含まれているということでしょうか。
> 
はい、含まれております。

> プログラムで、DB を読んで、外部データーと比較して、
> 相違のあるものだけ、UPDATE するようにしては如何でしょう。
> 殆んどのデーターが変更必要ならば、かえって遅くなる
> のでまずいですが、変更不要のデーターがある程度ある
> なら試してみる価値はあると思います。
> 
> ついでに、一時表に入れるのもやめて、外部データー
> (多分テキストファイル)から、プログラムで直接 INSERT/UPDATE
> したらどうなるでしょうか。諸処の条件によるので、早くなるか
> 遅くなるかわかりませんが。
> 
今回のWORKテーブルに入れて更新するという処理の前には、
近藤様のおっしゃってる通りの方法を考えておりました。
ただし、あまりにも時間がかかってしまったために
その処理はやめて、WORKテーブルに入れる方法に変更しました。
どうも70万回のSELECT文だけでもかなりの時間がかかっていたようです。
（そのときは全部で数時間単位の実行速度でした）

それで、いろいろ調査をしてみた結果、
UPDATEの場合もINSERTの場合もINDEXが使用されていないようです。
user_idの方はTB作成時にidをPRIMARY KEYにしていしてます。
また、work_user_tbの方はidでINDEXを作成しています。

これをIndex Scanにすることができれば、
少しは早くなるような気がするのですが・・・
ちなみに、それぞれをSQL文をSELECTに置き換えても同じ結果でした。

＝UPDATEの場合のEXPLAIN＝
Nested Loop  (cost=0.00..472022230.82 rows=2634084249 width=1784)
  ->  Seq Scan on user_tb  (cost=0.00..359796.33 rows=3629 width=957)
  ->  Seq Scan on work_user_tb  (cost=0.00..122708.21 rows=725821 width=827)

＝INSERTの場合のEXPLAIN＝
Merge Join  (cost=831927.47..844629.34 rows=725821 width=198)
  ->  Sort  (cost=327584.18..327584.18 rows=725821 width=132)
        ->  Seq Scan on work_user_tb  (cost=0.00..122708.21 rows=725821 width=132)
  ->  Sort  (cost=504343.29..504343.29 rows=725822 width=66)
        ->  Seq Scan on user_tb  (cost=0.00..356167.22 rows=725822 width=66)