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
