On Fri, Sep 5, 2014 at 9:34 PM, Walter Underwood
wrote:
> What would be a high mm value, 75%?
Walter, I suppose that the length of the search result influence the run
time. So, for particular query and an index, the high mm value is that
one, which significantly reduces the search result lengt
Sure. I created SOLR-6502. The tricky part was handling the behavior in a
sharded index. When the index is sharded. the response from each shard will
contain a parameter that indicates if the search results are from the
conjunction of all keywords (mm=100%), or from disjunction (mm=1). If the
shard
We do that strict/loose query sequence, but on the client side with two
requests. Would you consider contributing the QueryComponent?
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/
On Sep 10, 2014, at 3:47 AM, Peter Keegan wrote:
> I implemented a custom QueryCo
I implemented a custom QueryComponent that issues the edismax query with
mm=100%, and if no results are found, it reissues the query with mm=1. This
doubled our query throughput (compared to mm=1 always), as we do some
expensive RankQuery processing. For your very long student queries, mm=100%
woul
Great!
We have some very long queries, where students paste entire homework problems.
One of them was 1051 words. Many of them are over 100 words. This could help.
In the Jira discussion, I saw some comments about handling the most sparse
lists first. We did something like that in the Infoseek
indeed https://issues.apache.org/jira/browse/LUCENE-4571
my feeling is it gives a significant gain in mm high values.
On Fri, Sep 5, 2014 at 3:01 AM, Walter Underwood
wrote:
> Are there any speed advantages to using “mm”? I can imagine pruning the
> set of matching documents early, which could
