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

[Naritaka KAGA]

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

sugita ＠ sra.co.jp さんは書きました:
>  杉田です。
>
>From: tamagawa <tamagawa ＠ sts.co.jp>
>Subject: [pgsql-jp: 29328] Re: パフォーマンス向上策
>Date: Sun, 09 Mar 2003 15:39:13 +0900

>  PostgreSQL 7.3 からの PREPARE を試した一例です。
>
>    PREPARE name_to_cast (text) AS
>	SELECT t1.typname AS castsource,
>	       t2.typname AS casttarget,
>	       p.proname AS proname,
>	       p.provolatile AS provolatile,
>	       c.castcontext AS castcontext
>	    FROM pg_type t1, pg_type t2, pg_cast c, pg_proc p
>	    WHERE c.castsource = t1.oid
>		  AND
>		  c.casttarget = t2.oid
>		  AND
>		  c.castfunc = p.oid
>		  AND
>		  t1.typname = $1
>	    ORDER BY 1, 2
>	    ;
>
>    CPU, メモリ, OS          通常     PREPARE  EXECUTE (msec)
>    =======================  =======  =======  =======
>    Pentium 800MHz, 384MB       16.1     18.5     4.38
>    Red Hat Linux 7.3
>    =======================  =======  =======  =======

今回の件に関連して、少し質問させてください。
私が理解していたPrepare文の用途は、Statmentを見て、
optimizerがDB内の各テーブルの統計情報に基づき、最適なアクセスプランを
生成し、その後Preparがそのアクセスプランをキャッシュし、渡されるパラメータ
に関して、蓄積したアクセスプランを適用、結果を返すということですが。
つまり、同じパターンのSQL文のアクセスプラン生成するコンパイルプロセスが
なくなるということで、最初に一回呼ばれるとき、応答が遅いが、その次から
はめちゃはやというパフォーマンス的な表れになります。

当然このような、仕組みになってくると、不確かだけど、
・多いに効くのがWHERE CLAUSEであろう
上記は私の理解ですが。そもそも間違っていたら教えてください。

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

いずれ、今回の件、数万のテーブルを掘ってしまったのが問題で、
パフォーマンスがどうのこうのというよりもそのうち、パティショーン上のinode
がなくなり、停止または新規データの紛失になるでしょうね。作り変えるしかない
というのが個人的な考えです。


-----------------------------------------------------------------------------
加賀　斉天（かが　なりたか）      108-8345 東京都港区三田2-15-45   
（旧氏名：　斉　天）              慶應義塾  塾監局人事部情報環境担当     
Office of Human Resource Management Information Technology Support, KEIO        
2-15-45, Mita, Minato-Ku, Tokyo, JAPAN 
TEL: 03-5427-1668 / FAX: 03-5427-1722　Naritaka.KAGA (Ph. D.)