[pgsql-jp: 32975] Re: 問い合わせの速度低下
Mao Morimoto
yneko2 @ yamamaya.com
2004年 5月 19日 (水) 12:15:19 JST
もりもとです。
オプティマイザのあたりがよくわかってなかったので、
すみませんでした。EXPLAIN ANALYZEの結果は以下です。
(横に長いので途中で整形しました)
Aggregate (cost=657.31..657.31 rows=1 width=0)
(actual time=8.034..8.038 rows=1 loops=1)
-> Index Scan using i_result_3 on t_result
(cost=0.00..656.90 rows=166 width=0)
(actual time=0.057..6.843 rows=196 loops=1)
Index Cond: ((check_id = 256) AND
(check_sub = 0) AND
(time_smpl > '2004-05-16 09:00:00'::timestamp) AND
(time_smpl <= '2004-05-17 09:00:00'::timestamp))
Total runtime: 8.235 ms
今は、Index Scan + Filterというプランを選んでくれないので、
遅いときのパターンがわからないのですが・・今選ばれている3次元の
インデックスを削除して、強制的に以前の、CHECK_ID+CHECK_SUBの
2次元のインデックスと、TIME_SMPLをフィルタで、という状態にすると
Aggregate (cost=3421.32..3421.32 rows=1 width=0)
(actual time=108.272..108.276 rows=1 loops=1)
-> Index Scan using i_result_2 on t_result
(cost=0.00..3420.90 rows=166 width=0)
(actual time=49.913..106.608 rows=196 loops=1)
Index Cond: ((check_id = 256) AND (check_sub = 0))
Filter: ((time_smpl > '2004-05-16 09:00:00'::timestamp) AND
(time_smpl <= '2004-05-17 09:00:00'::timestamp))
Total runtime: 108.468 ms
このようになりました。(この予備の(?)2次元のインデックスを作っておかない
と、
フルにシーケンシャルスキャンになったのです・・)
データの性質は、
CHECK_IDとCHECK_SUBの組み合わせが500あって、それがそれぞれ1レコード
ずつ5分ごと(TIME_SMPL)に追加されるだけです。
(すなわち、一つのTIME_SMPLに対して500レコード、一つのCHECK_IDと
CHECK_SUBの組み合わせに対してTIME_SMPLの値は5分ごとの値となってます)
データの性質と、問い合わせの内容を考慮すると、CHECK_IDとCHECK_SUBとTIME_SMPL
の3次元のインデックスを作っておけばいいと思って設計していたのに、昨日までは
肝心のインデックスをなかなか使ってくれなかったので・・やっぱり統計情報の問題
なのでしょうか。。
Mao Morimoto
http://blog.yamamaya.com/
pgsql-jp メーリングリストの案内