[
https://issues.apache.org/jira/browse/LUCENE-8833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858120#comment-16858120
]
Robert Muir commented on LUCENE-8833:
-------------------------------------
I'm just curious about more details. For the merge use-case, it makes sense to
hint the operating system to do some read-ahead, since the bits will be
accessed sequentially. But this flag does a lot more than that, it will touch
every page too. It's too bad java has no other way to hit up madvise. :)
And isn't it the case the indexinput will already be open by IndexWriter? So
I've always been confused about the IOContext ctor for that reason. It almost
seems like {{clone(IOContext)}} would be more useful, we could practically do
something there.
Anyway, just some concerns about exposing too much of this flag. Even if you
can choose it based on arbitrary complex-logic, it would still be an
all-or-nothing "hammer" because of how java limits us as far as telling the OS
our intentions. The current IOContext is not really utilized much, because I
think the problem is hard.
> Allow subclasses of MMapDirecory to preload individual IndexInputs
> ------------------------------------------------------------------
>
> Key: LUCENE-8833
> URL: https://issues.apache.org/jira/browse/LUCENE-8833
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Simon Willnauer
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I think it's useful for subclasses to select the preload flag on a per index
> input basis rather than all or nothing. Here is a patch that has an
> overloaded protected openInput method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
