mikemccand commented on code in PR #13359:
URL: https://github.com/apache/lucene/pull/13359#discussion_r1609700636
##########
lucene/core/src/java/org/apache/lucene/codecs/lucene90/blocktree/SegmentTermsEnum.java:
##########
@@ -307,6 +309,30 @@ private boolean setEOF() {
return true;
}
+ @Override
+ public void prepareSeekExact(BytesRef target) throws IOException {
+ if (fr.index == null) {
+ throw new IllegalStateException("terms index was not loaded");
+ }
+
+ if (fr.size() == 0 || target.compareTo(fr.getMin()) < 0 ||
target.compareTo(fr.getMax()) > 0) {
+ return;
+ }
+
+ // TODO: should we try to reuse the current state of this terms enum when
applicable?
+ BytesRefFSTEnum<BytesRef> indexEnum = new BytesRefFSTEnum<>(fr.index);
+ InputOutput<BytesRef> output = indexEnum.seekFloor(target);
+ if (output != null) { // should never be null since we already checked
against fr.getMin()?
+ final long code =
+ fr.readVLongOutput(
+ new ByteArrayDataInput(
+ output.output.bytes, output.output.offset,
output.output.length));
+ final long fpSeek = code >>>
Lucene90BlockTreeTermsReader.OUTPUT_FLAGS_NUM_BITS;
+ initIndexInput();
+ in.prefetch(fpSeek, 1); // TODO: could we know the length of the block?
Review Comment:
Egads, that is really weird -- I would not expect those `fp` to go backwards
on `.next()` -- I thought the FST index was a depth-first traversal of all
on-disk (leaf) blocks. I will need to mull some more about this :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
