lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4872) BooleanWeight should decide how to execute minNrShouldMatch
Date Thu, 28 Mar 2013 01:21:16 GMT


Robert Muir commented on LUCENE-4872:

I really don't really know what the typical/common use cases are for

One very practical thing is that solr queryparsers (probably elasticsearch has similar ones
too?) such as dismax/edismax actually seem to be fully defined in terms of minShouldMatch
(with the extremes being handled as OR and AND). 

I know Tom Burton-West has experimented with this some on chinese TREC data (he has some comments
on SOLR-3589), etc.

> BooleanWeight should decide how to execute minNrShouldMatch
> -----------------------------------------------------------
>                 Key: LUCENE-4872
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Sub-task
>          Components: core/search
>            Reporter: Robert Muir
>             Fix For: 5.0, 4.3
>         Attachments: crazyMinShouldMatch.tasks
> LUCENE-4571 adds a dedicated document-at-time scorer for minNrShouldMatch which can use
advance() behind the scenes. 
> In cases where you have some really common terms and some rare ones this can be a huge
performance improvement.
> On the other hand BooleanScorer might still be faster in some cases.
> We should think about what the logic should be here: one simple thing to do is to always
use the new scorer when minShouldMatch is set: thats where i'm leaning. 
> But maybe we could have a smarter heuristic too, perhaps based on cost()

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message