-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Keep evaluating conjunction one doc-at-a-time until dynamic pruning kicks in. #14739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…icks in. This essentially reverts the change from apache#14701 for conjunctive queries that have not reached their `totalHitsThreshold` yet. This should speed up queries whose total number of matches is in the order of `totalHitsThreshold` or less, such as filtered conjunctions on nightly benchmarks.
|
On wikibigall: |
| float maxWindowScore = computeMaxScore(windowMin, windowMax); | ||
| scoreWindowScoreFirst(collector, acceptDocs, windowMin, windowMax + 1, maxWindowScore); | ||
| } else { | ||
| scoreWindowDocFirst(collector, acceptDocs, windowMin, windowMax + 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So minCompetitiveScore won't get a chance to be respected when filter clause leads the query because windowMax is DocIdSetIterator#NO_MORE_DOCS, could this cause regression?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we've always had this problem? I remember trying to make things better but it didn't look great or caused performance regressions with term queries, the case I care about the most.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we've always had this problem?
I agree that the previous version could not skip windows, but within window, it only needs to do conjunction with the competitive docs, while this PR could evaluate more.
I'm not sure how much this will affect though. FilteredAndHighHigh tasks should provide similar case and numbers not look bad. Let's move on.
…icks in. (#14739) This essentially reverts the change from #14701 for conjunctive queries that have not reached their `totalHitsThreshold` yet. This should speed up queries whose total number of matches is in the order of `totalHitsThreshold` or less, such as filtered conjunctions on nightly benchmarks.
|
This restored performance of filtered queries on nightly benchmarks: https://benchmarks.mikemccandless.com/FilteredAnd3Terms.html. And also improved combined conjunctions: https://benchmarks.mikemccandless.com/CombinedAndHighHigh.html. I'll push an annotation. |
This essentially reverts the change from #14701 for conjunctive queries that have not reached their
totalHitsThresholdyet. This should speed up queries whose total number of matches is in the order oftotalHitsThresholdor less, such as filtered conjunctions on nightly benchmarks.