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

[sugita ＠ sra.co.jp]

  杉田です。

From: Tsukasa Koizumi <tsukasa ＠ koiz.com>
Subject: [pgsql-jp: 29301] Re: パフォーマンス向上策
Date: Sat, 8 Mar 2003 16:12:45 +0900

;;; 同じ定義内容のテーブルUNIONで、継承が有効…というのはちょっと思い当た
;;; らないのですが、よろしければもう少し突っ込んでお教えいただけると嬉しい
;;; です。

  親テーブル = UNION 子テーブル、というようになるならばという考えです。

    =# explain select * from p where i = 100;
					QUERY PLAN                                     
    -----------------------------------------------------------------------------------
     Result  (cost=0.00..6.03 rows=3 width=4)
       ->  Append  (cost=0.00..6.03 rows=3 width=4)
	     ->  Seq Scan on p  (cost=0.00..0.00 rows=1 width=4)
		   Filter: (i = 100)
	     ->  Index Scan using c1_i_index on c1 p  (cost=0.00..3.01 rows=1 width=4)
		   Index Cond: (i = 100)
	     ->  Index Scan using c2_i_index on c2 p  (cost=0.00..3.01 rows=1 width=4)
		   Index Cond: (i = 100)
    (8 rows)

    =# 

  子テーブルの数だけスキャンして合算するというようにはなってしまうと思いますが。

;;; 前述のような代物なので、ユーザが一人増えると、決済履歴テーブルもひとつ
;;; 増えます。

  これは、あんまりな気がします。

  以降は、5 つのテーブルの場合に限るとします。

;;; >   まずは、EXPLAIN をしてみてはどうでしょう？
;;; 
;;; やってみたのですが、どうもよくわかりません。
;;; 結局、テーブル数が多い→ユーザが多い→データも多い…ということなので、
;;; データが多くなったからJOINが遅くなったのか、テーブルが多くなったから遅
;;; くなったのかの切り分けができなくて…。

  クエリー内容のチューニングするには EXPLAIN の他には方法はありませんから、マ
ニュアルを読んで、分かるようになるのが手っ取り早いです。

;;; ＃pg_dumpがコケるという弊害も発生中です。
;;; ＃テーブルの一覧を取得する際のLOCKで、共有メモリが足らなくなる(?)みた
;;; ＃いです。

  試しに増やしてみるというのはどうでしょう？しかし、ユーザ毎のテーブルというの
がここにも影響していそうです。


Kenji Sugita