まとめ

とはいうものの、同規模のDB検索処理を鑑みた時に、
OracleのPL/SQLのときはやっぱり早かったなと思う。
今回はPostgreSQLだけれどもストアドは使用していない。
現状でテンポラリ作成に5秒程度、各種マスタのデータをアップデートするのも
3秒程度が2回であることを思えばストアドでどこまで改善できるかを期待できる。
単純計算でも10秒切れそうに思える。

そんなことを考えてみれば、今回の対処として最善策はなんだったかと思えば
やはりストアドはキーポイントを握っていたと思える。
大量データを扱う検索において守るべきデータ形態や処理形態にパターンはそんなに無いのだ。

また、やったことあるという実績があればおいらは間違いなくその道を選んでいたことを思えば、
知識と経験不足が今回の四苦八苦を産み、自己反省の材料となったのだと感じる。
事前知識って大事だねぇ。
知識を吸収すべく調査し実験するという行為にかけれる情熱も大事だねぇ。
それが少ないから今回の対処になったのだから。

という事例に対する対処と結果を持ってまた次の経験としようと思いつつ。
今、実験でつくったプログラムを綺麗に整理整頓しよう。
テンポラリ作成〜アップデート２つ、全件検索〜ループまでが1ﾒｿｯﾄﾞ内にあるなんて
ソースを放置するなんてありえん。*1

*1:ちなみに150行程度。けどありえん。