Hi,
Thank you for your answer. Is it something that is somehow theoretically
quantifiable, or the only way to quantify the overhead is to prototype
and to benchmark?
Regards,
Aurelien
On 28.07.2015 17:15, Uwe Schindler wrote:
It depends on the number of fields. If you search on 3 fields it
You can always throw an exception in the collector to stop the collection
process.
Anton
On Tue, Jul 28, 2015 at 4:26 AM, Muhammad Ismail
wrote:
> Can we skip matching lucene document by using custom collector or some
> other way. Like I want to bring all document created by user xxx on
> speci
Muhammad Ismail gmail.com> writes:
Any one
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
It depends on the number of fields. If you search on 3 fields it is not likely
to be a problem (the general use case 3 fields: plain, stemmed, folded). But if
you have like 50 fields, the slow down is likely very large!
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi
Hi,
I am wondering about the real performance impact of searching across
multiple fields instead of using a catch-all field. I know that Lucene
is optimized to do that and that there are mechanisms to mitigate the
overhead but does anybody know if there are performance benchmarks
related to
Can we skip matching lucene document by using custom collector or some
other way. Like I want to bring all document created by user xxx on
specific date but after we got a match, we want to run some logic which
figure out either the document is acceptable or not. We cannot specify
criteria in lucen
