Re: analyzer context during search

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

What are other options for index backup/replication?

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

Re: what's replacement of FieldCache in Lucene 7

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

Re: what's replacement of FieldCache in Lucene 7

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

Re: what's replacement of FieldCache in Lucene 7

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

Re: what's replacement of FieldCache in Lucene 7

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