[
https://issues.apache.org/jira/browse/LUCENE-10061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435789#comment-17435789
]
Zach Chen commented on LUCENE-10061:
------------------------------------
Thanks for the confirmation [~jpountz]! I've actually given it a try in the
last few days and just opened a WIP PR
[https://github.com/apache/lucene/pull/418] for it, before seeing your comment
above.
>From the results of a few samples (documented in the PR), assuming there's no
>bug in the implementation, it does seem that the basic pruning would be most
>effective in the overall performance when there's significant difference in
>terms' doc frequencies (HighLow), but would indeed slow down when doc
>frequencies are close (HighHigh / HighMed) and very likely the overhead of
>combinatorial calculation / pruning logic outweighs the benefit of skipping. I
>will try to implement your optimization idea above as well and see how it
>performs.
In addition, I have been searching around to see if I can leverage luceneutil
for benchmarking, but I can't seem to find a way to express combined fields
query like those in
[https://github.com/mikemccand/luceneutil/blob/master/tasks/wikimedium.10M.tasks]
. I'm wondering if you may have any pointer for that as well?
> CombinedFieldsQuery needs dynamic pruning support
> -------------------------------------------------
>
> Key: LUCENE-10061
> URL: https://issues.apache.org/jira/browse/LUCENE-10061
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CombinedFieldQuery's Scorer doesn't implement advanceShallow/getMaxScore,
> forcing Lucene to collect all matches in order to figure the top-k hits.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
