msokolov commented on issue #14455: URL: https://github.com/apache/lucene/issues/14455#issuecomment-2798234028
We tie-break on docid so that the sort order is well-defined and stable w.r.t. multiple executions of the same query. Maybe there is some other reason like making index-time sorting more able to enable efficient querying. At first I thought it made no sense to support a query plan where we initially sort by one complex sort criterion and then later re-sort with another complex sort criterion since we could initially use no scoring, and only after in the rescoring phase, apply the combined sort. But then it occurred to me we might take top N by the first sort and then re-sort those. I see a problem here though which is that this rescoring is done per-segment, and the initial sort order is only every computed within a segment. We don't know what the relative order of two documents is across different segment until we merge the results, but QueryCollectorRescorer does its work per-segment, so I don't see how we can "preserve" an order that has not yet been determined. So maybe the only way forward here is to run the rescoring single-threaded after merging results from the first query. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
