We do that strict/loose query sequence, but on the client side with two requests. Would you consider contributing the QueryComponent?
wunder Walter Underwood [email protected] http://observer.wunderwood.org/ On Sep 10, 2014, at 3:47 AM, Peter Keegan <[email protected]> wrote: > 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% > would obviously be too high, so you'd have to experiment. > > On Fri, Sep 5, 2014 at 1:34 PM, Walter Underwood <[email protected]> > wrote: > >> 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 Ultra engine about >> twenty years ago. Short termlists (documents matching a term) were >> processed first, which kept the in-memory lists of matching docs small. It >> also allowed early short-circuiting for no-hits queries. >> >> What would be a high mm value, 75%? >> >> wunder >> Walter Underwood >> [email protected] >> http://observer.wunderwood.org/ >> >> >> On Sep 4, 2014, at 11:52 PM, Mikhail Khludnev <[email protected]> >> wrote: >> >>> 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 <[email protected]> >>> wrote: >>> >>>> Are there any speed advantages to using “mm”? I can imagine pruning the >>>> set of matching documents early, which could help, but is that (or >>>> something else) done? >>>> >>>> wunder >>>> Walter Underwood >>>> [email protected] >>>> http://observer.wunderwood.org/ >>>> >>>> >>>> >>> >>> >>> -- >>> Sincerely yours >>> Mikhail Khludnev >>> Principal Engineer, >>> Grid Dynamics >>> >>> <http://www.griddynamics.com> >>> <[email protected]> >> >>
