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

[sugita ＠ sra.co.jp]

  杉田です。

From: Naritaka KAGA <ten.chi ＠ adst.keio.ac.jp>
Subject: [pgsql-jp: 29359] Re: パフォーマンス向上策
Date: Mon, 10 Mar 2003 09:24:21 +0900

;;; はじめまして、加賀です。

  ばめまして。

;;; 私が理解していたPrepare文の用途は、Statmentを見て、
;;; optimizerがDB内の各テーブルの統計情報に基づき、最適なアクセスプランを
;;; 生成し、その後Preparがそのアクセスプランをキャッシュし、渡されるパラメータ
;;; に関して、蓄積したアクセスプランを適用、結果を返すということですが。
;;; つまり、同じパターンのSQL文のアクセスプラン生成するコンパイルプロセスが
;;; なくなるということで、最初に一回呼ばれるとき、応答が遅いが、その次から
;;; はめちゃはやというパフォーマンス的な表れになります。
;;; 
;;; 当然このような、仕組みになってくると、不確かだけど、
;;; ・多いに効くのがWHERE CLAUSEであろう
;;; 上記は私の理解ですが。そもそも間違っていたら教えてください。

  私の理解も同じです。ひとつの例を挙げただけなので、条件をやクエリーをいろいろ
変えて試すと、どれくらい速くなるかと言えるようになるのではないかと思います。

;;; 今回の件に関しては、テーブルをばら撒きすぎたという設計に由来しているので、
;;; この場合では、おそらくPrepareに代入パラメータがテーブル名になるとおもいます。
;;; つまり、
;;; 　　　select xxx from $1 
;;; のようなPrepare文になるとおもうのですが。
;;; この場合、疑問点としては、
;;; ・統計情報の継承(DB <-> table間)に関しては可能でしょうか。可能であれば、アクセスプランがひとつですむし
;;; 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　不可能であれば、何も変わりません。

  このパターンは、エラーとなりました。


Kenji Sugita