I think that's right Michael -- some null scorers.  Started with 3 in one
case and wound up with 1.

Also, in MinShouldMatchSumScorer.cost, sometimes the size of the
PriorityQueue isn't needed at all, which is when minShouldMatch is 0 or 1.
In that case, simply sum the costs.

On Thu, Jun 7, 2018 at 1:38 PM Michael McCandless <luc...@mikemccandless.com>
wrote:

> Doesn't BQ rewrite itself if it has only one clause?
>
> Or maybe if there were more than one clause, and then all but one of them
> had null scorers (on SHOULD clauses) you could wind up in that state?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Thu, Jun 7, 2018 at 1:21 PM, David Smiley <david.w.smi...@gmail.com>
> wrote:
>
>> I'm working with some folks who did some profiling and noticed that
>> ScorerSupplier.cost() can be expensive (as the javadocs say). cost() says
>> only to call it if necessary. Unfortunately, a BooleanQuery is going to
>> call cost() (via BooleanWeight.scorer() even if ultimately no Query in the
>> tree cares what the cost is.  I'm not sure if that's a perf bug or not;
>> it's hard to tell.
>>
>> The expensive part of cost() for Boolean2ScorerSupplier is over in
>> MinShouldMatchSumScorer.cost which creates a PriorityQueue every time, even
>> if trivially numScorers == 1.  That's a weird case... why do we even need a
>> Boolean2ScorerSupplier around one clause; couldn't that clause be returned
>> from the outer weight, BooleanWeight.scorerSupplier() close to the end as
>> an optimization?  I could file an issue.
>>
>> ~ David
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Reply via email to