[pgsql-jp: 29041] Re: Like を使った前方一致検索時のインデックス使用条件について
Tatsuo Ishii
t-ishii @ sra.co.jp
2003年 2月 14日 (金) 11:28:40 JST
石井です.
> 下が explain の結果です。
> cost は・・・・掛かってます! でも、速いですね。
>
>
> xxxdb=> SET ENABLE_SEQSCAN TO OFF;
> SET
> xxxdb=> explain select plan_id, kenmei from kenmei where mitumori LIKE 'SI%';
> QUERY PLAN
> ------------------------------------------------------------------------------------------------
> Index Scan using idx1_plan on kenmei (cost=0.00..1147.61 rows=1403 width=38)
> Index Cond: ((mitumori >= 'SI'::character varying) AND (mitumori < 'SJ'::character varying))
> Filter: (mitumori ~~ 'SI%'::text)
> (3 rows)
>
> xxxdb=> SET ENABLE_SEQSCAN TO On;
> SET
> xxxdb=> explain select plan_id, kenmei from kenmei where mitumori LIKE 'SI%';
> QUERY PLAN
> ----------------------------------------------------------------
> Seq Scan on kenmei (cost=0.00..423.27 rows=1403 width=38)
> Filter: (mitumori ~~ 'SI%'::text)
> (2 rows)
>
>
>
> さて、この結果を踏まえてどうするかですね。
うーむ,ちょっと方向性が違っているような.問題のLIKE検索の結果,1万件
(でしたっけ?)の中からあらかじめ4件位しか返ってこないことがわかって
いるのに,オプティマイザは1403件返ってくると思ってることが問題なんです
よ.なぜそうなるかというと,もちろんオプティマイザが参照する統計情報が
ちゃんとしていないからです.では毎晩vacuumdb -zしているにも関わらず,
なぜ統計情報がちゃんとしていないか?それはおそらくデータに大きな偏りが
あるからだと推測されます.ではどうしたら良いか?もっときめ細かく統計情
報を取るようにすれば改善する可能性があります.
ALTER TABLE kenmei ALTER COLUMN SET STATISTICS 20;
ANALYZE kenmei;
でよくならないでしょうか?(20はもしかしたら最大1000までの間でもっと大
きな数字にする必要があるかも知れません).
他の可能性としては,initdbするときに--no-localeを指定しなかったという
のも考えられます.localeが有効だと,LIKE/regeexの前方一致検索でもイン
デックスが使われません.
このあたりはどうですか?
P.S. SET ENABLE_SEQSCAN TO OFF; は良くわかっている人以外は乱用して
はいけません.
--
Tatsuo Ishii
pgsql-jp メーリングリストの案内