[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 メーリングリストの案内