[
https://issues.apache.org/jira/browse/LUCENE-7862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887001#comment-16887001
]
ASF subversion and git services commented on LUCENE-7862:
---------------------------------------------------------
Commit f026053d4d8269c7f7135d8a76ffa21235a05d4b in lucene-solr's branch
refs/heads/master from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f026053 ]
LUCENE-8914: Move compare logic to IntersectVisitor in
FloatPointNearestNeighbor (#783)
Move the logic for discarding inner modes to the IntersectVisitor so we take
advantage of the change introduced in LUCENE-7862
> Should BKD cells store their min/max packed values?
> ---------------------------------------------------
>
> Key: LUCENE-7862
> URL: https://issues.apache.org/jira/browse/LUCENE-7862
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Ignacio Vera
> Priority: Minor
> Fix For: 7.5, 8.0
>
> Attachments: LUCENE-7862.patch, LUCENE-7862.patch, LUCENE-7862.patch
>
>
> The index of the BKD tree already allows to know lower and upper bounds of
> values in a given dimension. However the actual range of values might be more
> narrow than what the index tells us, especially if splitting on one dimension
> reduces the range of values in at least one other dimension. For instance
> this tends to be the case with range fields: since we enforce that lower
> bounds are less than upper bounds, splitting on one dimension will also
> affect the range of values in the other dimension.
> So I'm wondering whether we should store the actual range of values for each
> dimension in leaf blocks, this will hopefully allow to figure out that either
> none or all values match in a block without having to check them all.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
