[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980559#action_12980559
]
Shai Erera commented on LUCENE-2793:
------------------------------------
bq. This way the bufferSize is settable by the user, which I don't think is
easily possible today (perhaps the main motivation for this issue?)
Exactly ! That's what I thought of this issue in the first place - allow the
app to more easily control the size of the buffers used by Lucene. That that
IOContext will allow me to set different bufferSizes per the work that Lucene's
doing (i.e. merge, search) is a bonus for me :).
I still think bufferSize can be used as a hint by the specific Directory impl,
but it should be there.
If we want to allow control of different buffer sizes per operation, then maybe
we can do the following:
* Set a default buffer size on IOContext.
* Add a setBufferSize(OpType type, int/long bufferSize)
* Add getBufferSize(OpType) -- returns the set buffer size, or the default if
not set.
I don't think it's too complicated and gives enough control to the application?
> Directory createOutput and openInput should take an IOContext
> -------------------------------------------------------------
>
> Key: LUCENE-2793
> URL: https://issues.apache.org/jira/browse/LUCENE-2793
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Reporter: Michael McCandless
> Attachments: LUCENE-2793.patch
>
>
> Today for merging we pass down a larger readBufferSize than for searching
> because we get better performance.
> I think we should generalize this to a class (IOContext), which would hold
> the buffer size, but then could hold other flags like DIRECT (bypass OS's
> buffer cache), SEQUENTIAL, etc.
> Then, we can make the DirectIOLinuxDirectory fully usable because we would
> only use DIRECT/SEQUENTIAL during merging.
> This will require fixing how IW pools readers, so that a reader opened for
> merging is not then used for searching, and vice/versa. Really, it's only
> all the open file handles that need to be different -- we could in theory
> share del docs, norms, etc, if that were somehow possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
