高見 直輝
takam****@orega*****
2016年 1月 19日 (火) 10:22:22 JST
高見です。
> LIKEの中ではバックスラッシュは特別な文字なのでエスケープしな
> いといけませんでした。
>
> なので、書き方は
>
> > 最後に、LIKE検索で\をエスケープした結果です。（結果：0件）
> > select lower(pathcombine(rootdir::text, path)) as tmp from TEST_TABLE
> > where
> > lower(pathcombine(rootdir,path)) LIKE lower('%\\st\\新しいフォルダー\\フォルダ%') AND
> > lower(pathcombine(rootdir,path)) @@ lower('"30"');
>
> が正しいです。
>
> PGroongaのログをみるとGroongaレベルではヒットしていそうなの
> で、PostgreSQLがrecheckしているときにレコードが減っているの
> ではないかと思います。
>
> EXPLAIN ANALYZE VERBOSE
> select lower(pathcombine(rootdir::text, path)) as tmp from TEST_TABLE
> where
> lower(pathcombine(rootdir,path)) LIKE lower('%\\st\\新しいフォルダー\\フォルダ%') AND
> lower(pathcombine(rootdir,path)) @@ lower('"30"');
>
> すると
>
> Rows Removed by Index Recheck: XXX
>
> みたいなのがでていると思います。
はい、ありました。
> recheckするときはシーケンシャルスキャンになります。シーケン
> シャルスキャンのときは「@@」はPGroongaの「@@」ではなく
> PostgreSQLが提供している「@@」(*)が使われます。
>
> (*) https://www.postgresql.jp/document/9.4/html/functions-textsearch.html
>
> これだと
>
> lower(pathcombine(rootdir,path)) @@ lower('"30"')
>
> はマッチしません。
>
> これは演算子の検索順序の問題で、pgroongaスキーマにある演算子
> をpg_catalogスキーマより検索するようにすればよいです。そうす
> ればシーケンシャルスキャンの時もPGroongaの「@@」が使われるか
> らです。具体的にはこうします。
>
> SET search_path = "$user",public,pgroonga,pg_catalog;
パラメータを定義した上で検索したら、正常な値が返ってくるようになりました。
> ドキュメントに説明を。。。まだ書いていませんでした。。。
> http://pgroonga.github.io/ja/reference/operators/query.html#sequential-scan
このパラメータって、ALTER DATABASE で定義すると問題あるでしょうか？
> もともと、PostgreSQLと同じ演算子を使った方が既存のPostgreSQL
> ユーザーになじみがあって使いやすいだろうと思っていたのですが、
> 実際は↑のような罠があるので、将来的に演算子を変えようと思っ
> ています。今考えているのは、ぜんぶ最初に「&」をつけて「&@」
> とか「&%」とか「&~」とかを考えています。最初に「&」を使って
> いる演算子が少なそうだからというのと、「&」はちょっと「G」に
> 似てい。。。なくもないからです。
・・・そこまでこじつけるなら＠Gとかで良いような気がします。
> >> 一つ確認なのですが、1.0.1を適用することで状況が改善する可能性はあります
> >> でしょうか？
> >> 現在1.0.0で動かしています。
>
> 残念ながら変わらないと思います。
了解しました。ありがとうございます。
-----------------------------
高見 直輝 <takam****@orega*****>
株式会社オレガ
TEL:03-3267-0150
FAX:03-3267-0180