On Thu, Aug 28, 2014 at 4:18 PM, Vitaly Funstein <vfunst...@gmail.com> wrote:
> Thanks for the suggestions! I'll file an enhancement request.
>
> But I am still a little skeptical about the approach of "pooling" segment
> readers from prior DirectoryReader instances, opened at earlier commit
> points. It looks like the up to date check for non-NRT directory reader
> just compares the segment infos file names, and since each commit will
> create a new SI file, doesn't this make the check moot?
The segments_N file can be different, that's fine: after that, we then
re-use SegmentReaders when they are in common between the two commit
points. Each segments_N file refers to many segments...
> private DirectoryReader doOpenNoWriter(IndexCommit commit) throws
> IOException {
>
> if (commit == null) {
> if (isCurrent()) {
> return null;
> }
> } else {
> if (directory != commit.getDirectory()) {
> throw new IOException("the specified commit does not match the
> specified Directory");
> }
> if (segmentInfos != null &&
> commit.getSegmentsFileName().equals(segmentInfos.getSegmentsFileName())) {
> return null;
> }
> }
>
> return doOpenFromCommit(commit);
> }
>
> As for tuning the block size - would you recommend increasing it to
> BlockTreeTermsWriter.DEFAULT_MAX_BLOCK_SIZE, or close to it?
You can set it (min and max) as high as you want; the only hard
requirement is that max >= 2*(min-1), I believe.
> And if I did
> this, would I have readability issues for indices created before this
> change?
It won't have any effect on them: these parameters are already "baked
into" those indices... only newly written indices with your custom
codec will write larger blocks.
> We are already using a customized codec though, so perhaps adding
> this to the codec is okay and transparent?
Hmmm :) Customized in what manner?
Mike McCandless
http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
