Re: Use SloppyPhraseScorer in SpanNearQuery

Hi Alan, Thank you for your answer: it is exactly what I need. Regards, Aurélien On 12.09.2015 11:21, Alan Woodward wrote: > If you're using lucene 5.3, you could create a modified version of > PayloadScoreQuery that just uses positions rather than payloads to modify the > score. >

Re: Use SloppyPhraseScorer in SpanNearQuery

Perfect, thank you :-) I was also wondering if I can take the absolute position of a term in the scoring calculation in my SpanNearQuery but I am not sure I can achieve this efficiently with a custom implementation of Similarity. I am thinking of two ways to achieve this (please tell me if I

Re: Use SloppyPhraseScorer in SpanNearQuery

Hi, Yes, thanks. If I want to customize this behavior (remove it or make it more or less important), is it correct to override the Similarity class to implement a new computeSlopFactor method? Thank you for your answer. Regards, Aurélien MAZOYER On 10.09.2015 12:37, Alan Woodward wrote:

Use SloppyPhraseScorer in SpanNearQuery

Hi all, SpanNearQuery and SloppyPhraseQuery can have similar behavior in some use cases. On the one hand, I have to distinguish between ordered and unordered terms (that’s enabled with SpanNearQuery) but on the other hand, I want to use the SloppyPhraseScorer, that takes the relative position

Use absolute term position for scoring

Hi all, I want to take into account the absolute position of the term for the score calculation. I found many threads that deal with this issue, and the answer is often: "use SpanFirstQuery". The problem with this approach is that it is too "boolean" for me (the document matches the spanfirstq

RE: Performance impact of searching across multiple fields

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

Performance impact of searching across multiple fields

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

Re: Query nested document

Hi András, Thank you for you answer. I read the links you sent and I think the following sentence : "Lastly, it is not possible to “cross reference” between nested documents. One nested doc cannot “see” another nested doc’s properties. For example, you are not able to filter on “A.name” but

Query nested document

Hi, I have question regarding nested document queries: For example, let’s say that I have the following book: Book _title: Nested document for dummies Chapter1_Title: Introduction Chapter1_Content: Nested documents are fun. Chapter2_Title: Which technology should I use? Chapter2_Content: Lucene o

RE: Search with term intersection

Hi Mike and Uwe, Thank you for your answers. It is clear, now. Regards, Aurélien On 10.10.2014 12:32, Uwe Schindler wrote: Hi, every segment is executed on its own (every segment is its own index). Every segment returns its own document ids and the result is the union of them ranked by score

Search with term intersection

Hi, I know that Lucene uses a skip-list algorithm to search very fast even if the query needs to calculate intersection between terms within a segment. But what happened if it needs to calculate an intersection between more than one segment? I suppose that skip-list cannot be used anymore. Wh