[jira] [Commented] (LUCENE-8950) FieldComparators Should Not Maintain Implicit PQs

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] [Commented] (LUCENE-8950) FieldComparators Should Not Maintain Implicit PQs

Shalin Shekhar Mangar (Jira)

    [ https://issues.apache.org/jira/browse/LUCENE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907069#comment-16907069 ]

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 details).

> 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: [hidden email]
For additional commands, e-mail: [hidden email]