SQLを最適化したつもりが、逆に激しく遅くなった。まだPostgreSQLでは複雑なSQLを駆使し出してまもないので、経験が必要だなあ。今のところ、サブクエリーに関しては本数を減らすよりも、単純なものをたくさん並べる方が速いみたい。
顕著だったのは、同じ関連テーブルに対する複数本のIN (SELECT)のOR。それを気を利かせて一本のIN (SELECT .. OR)にまとめたら激遅になった。インデックスも綿密に張ってあるのだが、EXPLAINで調べるとうまく使ってくれておらず、nested loopが発生していた。時間があったらOracleやMS SQL Serverで試してみるつもり。
PostgreSQL の IN は遅いですよ。EXISTS に書き直すと速くなる場合が多いようです。7.5 からは大きく改善されるようです。また、CPUが2個以上ある場合には、ORの代わりにUNIONを使うと別々に処理をしてくれるので速くなる場合があります。そのときは結果は異なるので適宜まとめる必要があって少々不便ですが、止むを得ないときもあります。
7.4でINがましになったというのを機にINに直したのです。実際、単純なケースではINの方が速くなりました。複雑になると遅いのでまだまだですね。7.5に期待したいと思います。
EXISTSだと条件式にパラメータが入るのでよほどINより最適化が難しい気がするんですが、どうして今まで遅かったんでしょうねえ。
検索言語インタプリタでユーザが立てた式を解析・最適化していくんですが、うまく最適化するのはなかなか難しいです。あるケースで速くなってもワーストケースで激遅になってしまったりすると没だし。
具体的なSQL式があってそれを最適化するのはそんなに難しくないんですが、ユーザの入力なので何が来るかわからない。。