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

Adrien Grand commented on LUCENE-7282:
--------------------------------------

One of my motivations for LUCENE-10162 was to enable us to do this sort of 
things automatically. For instance, {{LongField#newRangeQuery}} could return an 
{{IndexSortSortedNumericDocValuesRangeQuery}} that wraps an 
{{IndexOrDocValuesQuery}} that itself wraps a {{PointRangeQuery}} and a slow 
doc-values query.

bq. `TermQuery` on the leading sort field can be very fast since we can advance 
to the first docID, and only match to the last docID for the requested value. 
This would not be approximate, and should be lower risk / easier.

We are not doing this today, but that would be a good idea as this iterator 
would be much better at skipping.

> search APIs should take advantage of index sort by default
> ----------------------------------------------------------
>
>                 Key: LUCENE-7282
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7282
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Priority: Major
>
> Spinoff from LUCENE-6766, where we made it very easy to have Lucene sort 
> documents in the index (at merge time).
> An index-time sort is powerful because if you then search that index by the 
> same sort (or by a "prefix" of it), you can early-terminate per segment once 
> you've collected enough hits.  But doing this by default would mean accepting 
> an approximate hit count, and could not be used in cases that need to see 
> every hit, e.g. if you are also faceting.
> Separately, `TermQuery` on the leading sort field can be very fast since we 
> can advance to the first docID, and only match to the last docID for the 
> requested value.  This would not be approximate, and should be lower risk / 
> easier.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to