morit****@razil*****
morit****@razil*****
2015年 3月 13日 (金) 16:27:49 JST
この変更によって索引の静的構築時の作業領域が増えるということでしょうか？ alignmentも考えるとそこそこ増えるんでしょうかね。。 2015-03-13 15:41 GMT+09:00 Kouhei Sutou <kou****@clear*****>: > 森さん > > 須藤です。 > > 実装方法について相談です。 > > しばらく前にGRN_TOKEN_SKIPというのが導入されて、トークナイザー > 側で位置情報をいじれるようになりました。 > > 参考: > http://sourceforge.jp/projects/groonga/lists/archive/dev/2014-August/002639.html > > これを使うと、n番目のトークンがn番目の位置じゃなくなります。 > > 現在の静的インデックス構築ではn番目のトークンがn番目の位置だ > という前提になっているため、GRN_TOKEN_SKIPを使うと正しい位置 > 情報のインデックスを構築できなくて検索時にヒットするべきレコー > ドがヒットしなくなってしまいます。 > > これを解決するためにはn番目のトークンがn番目の位置という前提 > をやめて正しい位置情報を使う必要があります。（正しい位置情報 > はgrn_token_cursorというやつが知っています。） > > 問題はgrn_ii_buffer.block_bufにこの位置情報を入れる隙間がな > いことです。grn_ii_buffer.block_bufはgrn_id *になっていて、 > grn_idの空いている上位2ビットにセクション番号フラグと重みフ > ラグを入れて、grn_idの中にセクション番号か重みかトークンIDか > という情報を詰め込んでいます。 > > https://github.com/groonga/groonga/pull/301 > > というように上から3ビット目を位置情報フラグにするとgrn_idに > 位置情報も詰め込めるんですが、トークンIDが大きくなって3ビッ > ト目も使うようになると破綻します。 > > ということで、 > > grn_id *block_buf; > > を > > struct { > byte type; ← enumの方がよいけど、サイズが重要なら1バイトにする > union { > grn_id tid; > uint32_t sid; > uint32_t weight; > uint32_t pos; > } value; > } *block_buf; > > というようにtypeを別に確保するようにしてもよいでしょうか？ > > たぶん、grn_idに詰め込んでいるのは空間効率をあげるためだと思 > うのですが、隙間がないので増やしたいのです。。。 > > > -- > 須藤 功平 <kou****@clear*****> > 株式会社クリアコード <http://www.clear-code.com/> > > Groongaベースの全文検索システムを総合サポート: > http://groonga.org/ja/support/ > パッチ採用 - プログラミングが楽しい人向けの採用プロセス: > http://www.clear-code.com/recruitment/ > コードリーダー育成支援 - 自然とリーダブルコードを書くチームへ: > http://www.clear-code.com/services/code-reader/ > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev >
