[jira] [Commented] (LUCENE-10367) Use WANDScorer in CoveringQuery Can accelerate scorer time

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488992#comment-17488992 ] 

ASF subversion and git services commented on LUCENE-10367:
----------------------------------------------------------

Commit 18967e826cb904bf593837d71deda1d61793d609 in lucene's branch refs/heads/branch_9x from Adrien Grand
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=18967e8 ]

LUCENE-10367: Optimize CoveringQuery for the case when the minimum number of matching clauses is a constant.


> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org