Proposal for alternate way to traverse BKD tree with prefetching matching leaves for IO concurrency

[abiesps]

Description

I would appreciate feedback on BKD traversal with prefetching.

At a high level, this is what I am doing:

Start traversing the BKD tree as is,

If cell is inside the query
a) Call goes to prepareDocIDs method variation where if isLeaf is true.
b) Do not read the leaf node yet. Instead, get the leafOrdinal, if this leaf ordinal is in continuation to last matching leaf ordinal (which I am storing in visitor) i.e leafOrdinal == visitor.lastMatchingLeafOrdinal() + 1. Do not call prefetch as this should be hopefully taken care by kernel readaheads. Otherwise if its not a continuous match i.e leafOrdinal != visitor.lastMatchingLeafOrdinal() + 1, then call prefetch on this leaf node file pointer. Also store this leaf node fp in visitor for visting matching doc IDs later.
c) If its not a leafNode continue with recursion as is.
d) Visit the cached leaf node file pointers after recursion.

For remaining traversal code remains unchanged.

Related Issue

[github-actions]

This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR.

[abiesps]

I am looking for overall feedback on high level idea for this. I do want to make the api interfaces added/modified more cleaner and possibly minimal.
Based on the directional feedback, I'll also add more tests

[github-actions]

This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the [email protected] list. Thank you for your contribution!

[iverase]

In general, I am not in favour of adding a new intersects method to the PointValues API like you are doing with PointValues#intersectWithPrefetch. Prefetching should be an implementation detail and not leak to the API.

[abiesps]

Thanks for the feedback @iverase !! I'll hide prefetching detail into existing intersect api. That would need adding some new methods to existing Visitor.

[iverase]

That would need adding some new methods to existing Visitor.

As far as we can add some default implementation, we should be ok.

[abiesps]

@iverase I removed the new intersect api in PointValues. However I have to create a new visitor TwoPhaseVisitor because I want to cache the prefetched leaf blocks so that I can visit them after recursion. This is a new abstract class with some state. Let me know your thoughts on this.

[iverase]

I have been thinking in this change and I think the approach makes too many assumptions about how points are implemented under the hood. In general, I don't think prefetching belongs to this API

The PointValues API is a cursor-style API. It allows to navigate a tree-like structure and apply some operations on the nodes the "cursor" is currently positioned. This PR is introducing the concept of applying those operations on a node when we are positioned on a different node via visitDocIDs(long pos, IntersectVisitor visitor). This introduced position does not belong to the current API. The TwoPhaseIntersectVisitor introduces even more stuff.

In general, if you want to introduce something like that, you need to propose a new API for the PointTree trying to be as agnostic as possible from the current implementations and reason the need for it.

IMHO, prefetching is an implementation detail of the BKD tree and most of the changes should be in that area while the changes to the PointValues API should be minimal.

[abiesps]

hmm, thanks for the input @iverase . Let me try moving all the methods to BKDReader class. This would mean having the TwoPhaseIntersectVisitor definition in BKDReader and an intersect method in BKDReader that takes in TwoPhaseIntersectVisitor.
With this change there wont be any changes to the PointValues class.