lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: [VOTE] Commit LUCENE-843 (IndexWriter performance gains)
Date Mon, 02 Jul 2007 20:11:02 GMT
Also, is it worth considering a couple of things:

1. Do a build version release prior to committing (i.e. 2.2.1) that  
way we could isolate this change and do a separate release to 2.3.  I  
don't want to do releases just for the sake of releases, but I think  
we should at least prepare people that the next release (i.e. the one  
containing 843) has a significant change.  I don't think this patch  
warrants a major revision tick, but it does make sense to have people  
really scrutinize it and to have them know that there are significant  
gains to be had.

2. or, at a minimum, do a tag of the trunk right before committing.   
I just find explicit tags make it easier to rollback or compare diffs  
if need be

Note these suggestions are by no means a judgment of the quality of  
the patch, just some precautions before such a big change.

-Grant

On Jul 2, 2007, at 1:31 PM, Grant Ingersoll wrote:

>
> On Jul 2, 2007, at 9:35 AM, Michael McCandless wrote:
>
>> Hi,
>>
>> I'd like to commit LUCENE-843.
>>
>> The patch has gone through a number of iterations but the final
>> version that's there now (take9) is quite a bit cleaner & simpler  
>> than
>> the ones leading up to it and I believe ready.
>>
>> It provides solid indexing performance gains (between 2X-8X), but, it
>> is somewhat more complex than the current "single doc per segment"
>> approach and it does introduce a change to the index format (only  
>> when
>> autoCommit=false) whereby multiple segments can share a single set of
>> term vector & stored fields files.
>>
>
> +0 for now, I will try to review tonight or tomorrow night.  From  
> what I gather from reading the issue, etc. it sounds great and you  
> and others have put a lot of hard work into it.  Also, from some  
> benchmarking I have done, it seems to sit well with the notion of  
> optimizing merge factor, etc. based on the amount of memory available.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message