[
https://issues.apache.org/jira/browse/LUCENE-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273067#comment-17273067
]
Julie Tibshirani commented on LUCENE-7282:
------------------------------------------
Sorry [~atris] I missed this (didn't have emails set up correctly!) We indeed
added a new query to sandbox {{IndexSortSortedNumericDocValuesRangeQuery}} that
optimize this case for range queries on numeric doc values. Since exact queries
on numerics are usually modelled as range queries on [value, value], this would
apply to exact queries as well (although I don't think we explicitly detect
that case, so we may end up doing extra work). I agree it'd be great to explore
other ways to leverage the index sort in queries.
> 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.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
