[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980564#action_12980564
]
Robert Muir commented on LUCENE-2793:
-------------------------------------
bq. But your code example tells me that if I want to control the buffer size
used by Lucene (whether it's done intelligently or not today is what we try to
fix here), I need to create my own Dir impl. That seems an overkill to me, for
just controlling the bufferSize !?
No you dont... you can also call the .setBufferSize like the skiplist reader
does.
{noformat}
IndexInput input = dir.openInput(....)
if (input instanceof BufferedIndexInput)
...setBufferSize(whatever_you_want);
{noformat}
Because after all, buffersize only makes sense on Buffered*.
It makes no sense to be on Directory's openInput, e.g. it makes no sense for
directories like MMapDirectory.
> 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
