Got it, make sense. Thanks Adrien.
2018-04-13 19:16 GMT+08:00 Adrien Grand :
> Queries should be fine: they are required to produce sorted iterators since
> 5.0 when we removed the accetDocsOutOfOrder option on collectors.
>
> Le ven. 13 avr. 2018 à 13:10, Yonghui Zhao a
> écrit :
>
> > I can
Queries should be fine: they are required to produce sorted iterators since
5.0 when we removed the accetDocsOutOfOrder option on collectors.
Le ven. 13 avr. 2018 à 13:10, Yonghui Zhao a écrit :
> I can sort doc id and then fetch field via docvalue.
>
> but another big scenario for field cache i
I can sort doc id and then fetch field via docvalue.
but another big scenario for field cache is in custom score query, we use
field cache to compute score, stored fields can't work here for performance
issue.
If I still use docvalue, I must make sure all queries are scored in order,
I think thi
Performance may be worse with stored fields indeed. In general Lucene makes
the assumption that millions of documents are queried but only ~100
documents are retrieved in the end, so the bottleneck should be query
processing, not retrieving stored fieds.
Le ven. 13 avr. 2018 à 05:27, Yonghui Zhao
My case is when I get some docs from lucene, I need also get some field
value of the retrieved docs.
For example in lucene 4, I use FieldCache like this.
FieldCache.DEFAULT.getTerms(reader, name, false).get(locDocId).utf8ToString();
FieldCache.DEFAULT.getInts(reader, name, false).get(locDocId);
Hello,
Doc values should be used instead of the field cache indeed. Note that this
require to add them to your documents at index time, eg. with a
NumericDocValuesField.
Regarding random access, maybe you can use the advanceExact API, which
exists on all doc-value iterators. Just make sure to nev
