[pgsql-jp: 29354] Re: パフォーマンス向上策

[Makoto,Yui]

油井です.
ちょっと乗り遅れ気味ですが.

> ところがPHP+PostgreSQLの場合、少なくとも現時点ではSQL文の解釈
> と実行を別々に行う関数がないので、必ず毎回プランナの動作が入って
> しまいます。

http://pear.php.net/manual/en/core.db.prepare.php
phpの場合は, pearなんかのprepareを使うとよいのでは...?
DBサーバによるものではないですが, SQL文の解釈と実行を別々に行えますよね.

Oracleはあまり使ったことないので詳しい所はわからないのですが, 
実行プランをキャッシュするという話で, データに新鮮さが要求される場合に
逆効果の場合もあるのではないでしょうか(?
#それも考慮されて設計されているのかもしれませんが..

Oracleが早いというのは, Oracle自体がある程度(メモリなど)高スペックな環境で
巧く動作するようなアルゴリズムが取られているとが影響してると思います.

PostgreSQLは低スペックなマシンでもまともに動きますが, それでも動くような
アルゴリズムを採用してるとかではないかと..(歴史あるプロジェクトのようですし.
#それとも既にリファクタリングされ, sortバッファー増やすとかパラメタで調整できるレベルの
#ものかもしれません

#[pgsql-jp: 29329]で杉田さんの指摘でPostgreSQL7.3からprepare,executeが導入されていたことを
#知りました^^;

話は反れますが, PostgreSQLのViewは, Ruleベースのrewrite(->PARSER->(rewirte?)->PLANNER->OPTIMIZER->EXECUTOR)
だったと思うので, prepare(->PARSER->EXECUTOR)を代替として使える場面_も_ありそうですね.

バッチで統計情報に基づいたプランを再構成する必要はありそうですが, GEQOのパラメタを調整して
よりよいプランを生成後, 他の問い合わせでは逆効果なパラメタを戻すとかも場合によっては.
#Documentで指摘されているように統計情報が頻繁に更新される必要が無い場合ですが.

多テーブル(11個以上)とかならGEQOのパラメタは再考したほうがよいと思います.
もしくはSQLを見直すとか..
明示的にJoinするテーブルを指定して, Plannerを仕向けコストベースで評価した結果何十倍と早くなったりします.

JDBCについては, (当然ですけど)結果セットが大きい場合, メモリを結構圧迫するので
できれば(余裕があれば)DBサーバと別マシンで実行エンジン動かすとかしたほうがよいのでは, と思います.
そしたら今度はネットワークの性能もってなりますが^^;


+-------------------------------------------------------------------+
Makoto, Yui <yuin ＠ bb.din.or.jp>
Key fingerprint = 6462 E285 97D8 1323 40C4  F9E5 EB0F 9DE6 1713 219E
+-------------------------------------------------------------------+