Adrien Grand commented on LUCENE-8950:

This looks like a duplicate of LUCENE-8878?

I think all of us agree on the fact that it would be nice to have a simpler 
FieldComparator API. The challenge is that we don't want to trade too much 
efficiency. For instance the API you are proposing wouldn't work well with 
geo-distance sorting since it would require computing the actual distance for 
every new document, while the current implementation tries to be smart to first 
check a bounding box, and then compute a sort key that compares like the actual 
distance but is much cheaper to compute (see discussion on LUCENE-8878 for more 

> FieldComparators Should Not Maintain Implicit PQs
> -------------------------------------------------
>                 Key: LUCENE-8950
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8950
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Atri Sharma
>            Priority: Major
> While doing some perf tests, I realised that FieldComparators inherently 
> maintain implicit priority queues for maintaining the sorted order of 
> documents for the given sort order. This is wasteful especially in the case 
> of a multi feature sort order and a large number of hits requested.
> We should change this to have FieldComparators maintain only the top and 
> bottom values, and use them as barriers to compare

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to