[
https://issues.apache.org/jira/browse/LUCENE-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859708#comment-16859708
]
Elbek Kamoliddinov commented on LUCENE-8791:
--------------------------------------------
{quote}Do you just accept the decrease of precision if one slice didn't collect
enough hits, or do you re-run the search on this slice with a greater number of
hits?
{quote}
We don't rerun, just accept the result. This approach has been working fine.
{quote}I won't veto this change, but could we make the single-threaded
constructor take a Collector rather than a CollectorManager and document that
the one that takes an ExecutorService is expert and usually doesn't help
significantly?
{quote}
Hmm, how do we return {{TopDocs}} from {{Collector}} interface? As I understand
{{Collector}}/{{LeafCollector}} doesn't make any assumption on how collected
docs sorted, scored etc. So is it even possible to build {{TopDocs}} from
{{Collector}}? With {{CollectorManager}} user plugs in this logic. Taking
{{Collector}} object in the constructor feels like bad api and feels confusing.
I added Expert comment in the last patch. So patch has a sole ctor:
{code}
public CollectorRescorer(CollectorManager<C, TopDocs> manager) {
this.manager = manager;
}
{code}
> Add CollectorRescorer
> ---------------------
>
> Key: LUCENE-8791
> URL: https://issues.apache.org/jira/browse/LUCENE-8791
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Elbek Kamoliddinov
> Priority: Major
> Attachments: LUCENE-8791.patch, LUCENE-8791.patch, LUCENE-8791.patch,
> LUCENE-8791.patch
>
>
> This is another implementation of query rescorer api (LUCENE-5489). It adds
> rescoring functionality based on provided CollectorManager.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
