[
https://issues.apache.org/jira/browse/LUCENE-9335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335125#comment-17335125
]
Zach Chen commented on LUCENE-9335:
-----------------------------------
I've implemented the above strategy and opened a new PR for it
[https://github.com/apache/lucene/pull/113.] I was using a _BulkScorer_ on top
of a collection of _Scorers_ though, instead of a _BulkScorer_ on top of a
collection of _BulkScorers_ like _BooleanScorer_, and hope the difference is
due to algorithm difference rather than me misunderstanding the intended usage
of BulkScorer interface :D . The result from benchmark util still shows it's
slower than _WANDScorer_ for 2 clauses queries, especially for OrHighHigh task.
During the implementation of this BulkScorer I also realized there were some
issues with the other PR I published earlier, so I'll fix them next and see if
that will give us better result.
> Add a bulk scorer for disjunctions that does dynamic pruning
> ------------------------------------------------------------
>
> Key: LUCENE-9335
> URL: https://issues.apache.org/jira/browse/LUCENE-9335
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Priority: Minor
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Lucene often gets benchmarked against other engines, e.g. against Tantivy and
> PISA at [https://tantivy-search.github.io/bench/] or against research
> prototypes in Table 1 of
> [https://cs.uwaterloo.ca/~jimmylin/publications/Grand_etal_ECIR2020_preprint.pdf].
> Given that top-level disjunctions of term queries are commonly used for
> benchmarking, it would be nice to optimize this case a bit more, I suspect
> that we could make fewer per-document decisions by implementing a BulkScorer
> instead of a Scorer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
