Re: ScorerSupplier and cost() avoidance

2018-06-07 Thread Adrien Grand
Got it. I thought you were talking about the class method, not the static function. Le jeu. 7 juin 2018 à 22:34, David Smiley a écrit : > I'll have to look further with the team on what these queries look like in > terms of relative cheapness and throughput. > > RE

Re: ScorerSupplier and cost() avoidance

2018-06-07 Thread David Smiley
I'll have to look further with the team on what these queries look like in terms of relative cheapness and throughput. RE MinShouldMatchSumScorer.cost() (static method called by Boolean2ScorerSupplier.computeCost) -- it's pretty easy to see that this is called with minShouldMatch==0 (or 1). Set

Re: ScorerSupplier and cost() avoidance

2018-06-07 Thread Adrien Grand
I suspect this could only show up as a bottleneck if they run very cheap queries (low cost) at a very high throughput? Is it the case? I've seen a couple workloads like that in the past and profilers suggested that things that usually do not matter were bottleneck like creating scorers or deciding

Re: ScorerSupplier and cost() avoidance

2018-06-07 Thread David Smiley
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

Re: ScorerSupplier and cost() avoidance

2018-06-07 Thread Michael McCandless
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