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
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
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
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
Hello,
I have an application that uses lucene indexes and we generate a single
index for all data.
I want to take a weekly *local* backup of the index quitely and
asynchronously.
So far I've tried:
1. The replicator module - I found it very complicated for what I just want
to copy and paste indexes
Hi,
Thanks for the thoughts. I agree a combinatorial explosion of fields and index
size would “solve” the problem but the cost is rather absurd. Hence, I posed
the problem to prompt some discussion about what a plausible/reasonable
solution might be.
It has seemed to be for some time that ther