[
https://issues.apache.org/jira/browse/LUCENE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17475370#comment-17475370
]
LuYunCheng commented on LUCENE-10367:
-------------------------------------
> Your patch is only rewriting to a BooleanQuery when the value is 1, but this
>would work for any value right?
[~jpountz] I think it is correct, but we need verify the
ConstantLongValuesSource is less than queries.size()
> Use WANDScorer in CoveringQuery Can accelerate scorer time
> ----------------------------------------------------------
>
> Key: LUCENE-10367
> URL: https://issues.apache.org/jira/browse/LUCENE-10367
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/query/scoring, core/search, modules/sandbox
> Reporter: LuYunCheng
> Priority: Major
> Attachments: LUCENE-10367.patch, TestCoveringQueryBench.java
>
>
> When using CoveringQuery In Elasticsearch with terms_set query, it takes too
> much time in CoveringScore and major cost in matain the DisiPriorityQueue:
> subScorers.
> But when minimumNumberMatch is ConstantLongValuesSource, we can use
> WANDScorer to optimize it.
>
> i do a mini benchmark with 1m docs, which code in LUCENE-10367.patch
> TestCoveringQuery.java testRandomBench()
> it shows:
> TEST: WAND elapsed 67ms
> TEST: NOWAND elapsed 163ms
> My testing environment is macBook with Intel Core i7 16GMem.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
