[pgsql-jp: 29047] Re: Like を使った前方一致検索時のインデックス使用条件について

[Hajime Lucky Okada]

岡田です。

石井さん、ありがとうございます。
そうなんですよね。  おっしゃる通りです。。。

３点あります。

１．オプティマイザが 1403 件返してくる件ですが、4件 (今はちょっと増えて
    13件) しかヒットしないはずなのに、確かに私もなぜこんな値が表示されるのか
    不思議に思っていました。

    データに偏りがあるか。  確かにあります。  例えば XXAAAA という番号が
    あれば、次に新規が足されると XXAAAB という形で番号が形成されていくので
    データ的には上の桁に行く程変化は無くなります。

    ALTER TABLE の件ですが、この 20 という数字の設定の仕方、私も調べてみますが
    何か基準はあるのでしょぅか？   少し調査が必要と考えますので、先ずは次項を
    先に試してみようと思います。

２．--no-locale の件
    Release Note?  これもどの種類か忘れましたが、./configure する際にも
    指定すべき、という記述を目にしたことがあります。 過去ログにもあったので
    今回 投稿する際、この記述を入れるべきかどうか迷ってました。
    で、現状は確かに configure 時にも initdb 時にも指定してはいませんでした。

    ビルドし直しというのはちょっと負荷が重いので、initdb からでも良いというので
    あれば、一度 早急に試してみたいと思います。

３．SET ENABLE_SEQSCAN TO OFF
    おっしゃってはる事とこちらの疑念がそのまま合っていたのですが
    全ての問い合わせに適用されてしまうのではないか、ということでは
    その通りでしたね。  ということは、「特定の」問い合わせだけに
    したいとすれば、select 発行の直前に これを実行しなければならない？
    ということですよね。  ==  コードの修正。。。  
    出来れば、避けたいところです (^^;;

    何とか DB の箱側の設定での改善を目指したいところです。


みなさん、ありがとうございます。
岡田はじめ



Tatsuo Ishii wrote:
> 石井です．
> 
> うーむ，ちょっと方向性が違っているような．問題の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
> 
>