[GitHub] [lucene] jpountz commented on a diff in pull request #12055: Better skipping for multi-term queries with a FILTER rewrite.

["jpountz (via GitHub)" <gi...@apache.org>]

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-unsubscribe@lucene.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org