rmuir commented on code in PR #13359:
URL: https://github.com/apache/lucene/pull/13359#discussion_r1597522761
##########
lucene/core/src/java/org/apache/lucene/codecs/lucene90/blocktree/SegmentTermsEnum.java:
##########
@@ -307,6 +309,31 @@ 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);
+ 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();
+ final long fp = in.getFilePointer();
+ in.seek(fpSeek);
+ in.prefetch(1); // TODO: could we know the length of the block?
+ in.seek(fp); // TODO: do we actually need to do this?
Review Comment:
I really don't like these calls to `seek()` just to prefetch data. Since it
is just prefetching, I'd prefer if this "dance" was an impl detail, if needed.
It would make the code simpler to just pass parameter to prefetch rather
than do this.
Then it is clear that the default implementation won't cause harm
(unnecessary io) for any directory subclasses
So I think prefetch should take location as argument? It is just a hint and
not real i/o by the thread. It's intentionally not sequential and sequential
API for it only hurts.
--
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
