[
https://issues.apache.org/jira/browse/LUCENE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243129#comment-17243129
]
Ignacio Vera commented on LUCENE-9619:
--------------------------------------
I see, yes DocIdSetIterator is not an option then.
so you manually visit each leaf node for IntersectsAll to make sure you only
hold documents for one leaf at a time. The only frustrating thing of that
approach is that you might need to copy the int array generated by the tree
into another array in the IntConsumer? But anyway I see your point.
Yes, I think the predicate is a good option to avoid the intersectVisitor
> Move Points from a visitor API to a custor-style API?
> -----------------------------------------------------
>
> Key: LUCENE-9619
> URL: https://issues.apache.org/jira/browse/LUCENE-9619
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Priority: Minor
>
> Points' visitor API work well but there are a couple things we could make
> better if we moved to a cursor API, e.g.
> - Term queries could return a DocIdSetIterator without having to materialize
> a BitSet.
> - Nearest-neighbor search could work on top of the regular API instead of
> casting to BKDReader
> https://github.com/apache/lucene-solr/blob/6a7131ee246d700c2436a85ddc537575de2aeacf/lucene/sandbox/src/java/org/apache/lucene/sandbox/document/FloatPointNearestNeighbor.java#L296
> - We could optimize counting the number of matches of a query by adding the
> number of points in a leaf without visiting documents where there are no
> deleted documents and a leaf fully matches the query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
