jpountz commented on code in PR #12055:
URL: https://github.com/apache/lucene/pull/12055#discussion_r1118982580
##########
lucene/core/src/java/org/apache/lucene/search/DisiWrapper.java:
##########
@@ -57,4 +56,13 @@ public DisiWrapper(Scorer scorer) {
matchCost = 0f;
}
}
+
+ public DisiWrapper(DocIdSetIterator iterator) {
+ this.scorer = null;
+ this.iterator = iterator;
+ this.cost = iterator.cost();
+ this.twoPhaseView = null;
+ this.approximation = iterator;
+ this.matchCost = 0;
+ }
Review Comment:
I wonder if we can keep the API a bit cleaner and change callers to do `new
DisiWrapper(new ConstantScoreScorer(itiretar))` instead.
##########
lucene/CHANGES.txt:
##########
@@ -277,6 +277,9 @@ Improvements
* GITHUB#12070: Compound file creation is no longer subject to merge
throttling.
(Adrien Grand)
+* GITHUB#12055: Better skipping support for multi-term queries that have a
+ FILTER rewrite. (Adrien Grand, Greg Miller)
Review Comment:
Maybe update this change log to mention that a new rewrite method was
introduced and what queries specifically switched to this new rewrite method as
a default?
##########
lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/CommonQueryParserConfiguration.java:
##########
@@ -55,12 +58,14 @@ public interface CommonQueryParserConfiguration {
public boolean getEnablePositionIncrements();
/**
- * By default, it uses {@link MultiTermQuery#CONSTANT_SCORE_REWRITE} when
creating a prefix,
- * wildcard and range queries. This implementation is generally preferable
because it a) Runs
- * faster b) Does not have the scarcity of terms unduly influence score c)
avoids any {@link
- * TooManyListenersException} exception. However, if your application really
needs to use the
- * old-fashioned boolean queries expansion rewriting and the above points
are not relevant then
- * use this change the rewrite method.
+ * By default QueryParser uses {@link
+ * org.apache.lucene.search.MultiTermQuery#CONSTANT_SCORE_BLENDED_REWRITE}
when creating a {@link
+ * PrefixQuery}, {@link WildcardQuery} or {@link TermRangeQuery}. This
implementation is generally
+ * preferable because it a) Runs faster b) Does not have the scarcity of
terms unduly influence
+ * score c) avoids any {@link
org.apache.lucene.search.IndexSearcher.TooManyClauses} exception.
+ * However, if your application really needs to use the old-fashioned {@link
BooleanQuery}
Review Comment:
maybe mention the non-blended constant-score rewrite as another alternative?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
