Kentaro Hayashi
hayas****@clear*****
2017年 8月 30日 (水) 18:54:12 JST
林です。 On Fri, 25 Aug 2017 21:55:04 +0900 murata satoshi <murat****@gmail*****> wrote: > むらたです。お世話になっております。 > indexを使ったin_valuesで不具合を見つけましたので報告させていただきます。 > 報告ありがとうございます！ > ■ 現象 > indexを使ったin_values(target, value1, ..., valueN)でvalueNの数が増えると正しい結果を取得できない。 > (具体的には126件までしか持ってこれない) > > ■ 環境 > Amazon Linux(AMI 2017.03.1) > groonga:7.0.5 > > ■ 再現手順 > *mroongaから作成/更新している環境で発覚しましたが、groonga単体でも起こるのでgroonga単体で。 > *長くなってすみません。。 > 再現手順があるととても助かります！ > groonga -n /tmp/test.db > >table_create --name test_table --flags TABLE_PAT_KEY --key_type UInt32 > >column_create --table test_table --name id --flags COLUMN_SCALAR --type UInt32 > >table_create --name test_table_index --flags TABLE_PAT_KEY --key_type UInt32 > >column_create --table test_table_index --name id --flags COLUMN_INDEX --type test_table --source id > > **別件ですが、schema打った時に、indexカラム作成のcommandが[--sources]になってますね。。 > > schema --output_pretty yes これはGroonga 7.0.6では修正されています。 > ... > "command_line": "column_create --table test_table_index --name id --flags COLUMN_INDEX --type test_table --sources id" > ... > snip > > >select test_table --filter 'in_values(id,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128)' --cache no > [[0,1503663680.514779,0.02670073509216309],[[[126],[["_id","UInt32"],["_key","UInt32"],["id","UInt32"]],[1,1,1],[2,2,2],[3,3,3],[4,4,4],[5,5,5],[6,6,6],[7,7,7],[8,8,8],[9,9,9],[10,10,10]]]] > > ...126件までしか持ってこれないようです。これ以上多くしても一律で126件になります。 > > ログへは以下が出力されていました(level:DEBUG) > [table][select][index][selector][in_values] <test_table_index.id> > [object][search][index][key][exact] <test_table_index.id> > grn_ii_sel > () > n=1 () > exact: 1 > hits=1 > ...以下126まで続く。 > (それ以外のエラー等は出力されていません。) > **** > idにindex作らない場合は以下でした。（no-indexなので件数多くなると遅いです。結果は正しい） > [table][select][index][selector][no-index][in_values] <test_table> > -- > idではなく_keyでやった場合は以下でした。(件数多くなると遅いです。結果は正しい) > [table][select][index][selector][in_values] <> > -- > in_values()ではなく、id==1||id==2...(或いは_key==1||_key==2...)では以下。 > (正しい結果が取得でき速度的にも問題ありません。) > [table][select][index][equal] <test_table_index.id> > [table][select][index][equal][accessor][key] <test_table> > -- 確認してみたら、in_valuesの引数として受け付けるのは126個まででした。 ソースコードにハードコーディングされている値で、あとから変更する感じのものではなかったです。 別案として、in_valuesでチェックするパターンがほぼ固定(あっても数パターン程度)なら in_recordsを使ってみるのはどうでしょう。 上記に加えて条件テーブルを定義して、 table_create conditions TABLE_NO_KEY column_create conditions value_pattern COLUMN_SCALAR UInt32 column_create test_table value_index COLUMN_INDEX conditions value_pattern load --table conditions [ {'value_pattern': 1}, {'value_pattern': 2}, {'value_pattern': 3}, ... ] select test_table \ --filter 'in_records(conditions, id, "==", "value_pattern")' \ --cache no などとすれば似たようなことはできそうです。 -- Kentaro Hayashi <hayas****@clear*****> -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し 型: application/pgp-signature サイズ: 833 バイト 説明: 無しDownload