That's right. In 3x though you have to call addIndexes followed by
maybeMerge if you want to achieve the same effect of
addindexesNoOptimize.
Shai
On Friday, November 12, 2010, Marc Sturlese wrote:
>
> Thanks, so clarifying. As far as I've understood, if I have to end up
> o
Thanks, so clarifying. As far as I've understood, if I have to end up
optimizing the index just after merging it, no matter if I use the lucene
3.X addIndexes or addIndexesNoOptimize as the sum of time of doing both
things will be the same in one case or other. Am I right?
--
View this me
es which accepts Directory, if after the merge
> I
> need to optimize the index using compound file, what would happen? Would
> this optimize be slower than if I use the addIndexesNoOptimize?
>
> >> But note that not running merges, or letting them finish, is not
> >&
tory, if after the merge I
need to optimize the index using compound file, what would happen? Would
this optimize be slower than if I use the addIndexesNoOptimize?
>> But note that not running merges, or letting them finish, is not
>> recommended long term. The approach I've me
into 6... till geting
> a single big index. Could this be faster?
>
> Does anyone have experience with this? Any advice?
> Thanks in advance
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/performance-merging-indexes-with-addIndexesNoOptimize-tp18893
uld this be faster?
Does anyone have experience with this? Any advice?
Thanks in advance
--
View this message in context:
http://lucene.472066.n3.nabble.com/performance-merging-indexes-with-addIndexesNoOptimize-tp1889378p1889378.html
Sent from the Lucene - Java Users mailing list archive
ndard
> technique is to allocate each segment a range of values, based on the range
> of numbers used in that segment. To convert a document number from a segment
> to an external value, the segment's base document number is added."
>
> Does assinging docids in addIndexesN
that it would be in some other
>> version,
>> >> Lucene makes no promises here.
>> >>
>> >> All the advice I've ever seen says that if you want to keep track of
>> >> documents, you assign and index your own ID. You can get the
>> >
Erick
> >>
> >> On Wed, Nov 4, 2009 at 9:23 AM, Britske wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> say I have:
> >>> - Indexreader[] readers = {reader1, reader2, reader3} //containing all
> >>> different do
>>> Does doing IndexWriter.addIndexesNoOptimize(Indexreader[] readers) on
>>> these
>>> readers give me a determinstic and calculable set of docids on the
>>> documents
>>> in the resulting documentWriter?
>>>
>>> i.e: from http://l
;The numbers stored in each segment are unique only within the segment,
>> and
>> must be converted before they can be used in a larger context. The
>> standard
>> technique is to allocate each segment a range of values, based on the
>> range
>> of numbers used i
the segment, and
> must be converted before they can be used in a larger context. The standard
> technique is to allocate each segment a range of values, based on the range
> of numbers used in that segment. To convert a document number from a
> segment
> to an external value, the seg
Just to clarify question changed the subject:
addIndexesNoOptimize on shards --> is docid deterministic and calculable?
(IF docids of shards seperately are known)
Britske wrote:
>
> Hi,
>
> say I have:
> - Indexreader[] readers = {reader1, reader2, reader3} //containi
ndard
technique is to allocate each segment a range of values, based on the range
of numbers used in that segment. To convert a document number from a segment
to an external value, the segment's base document number is added."
Does assinging docids in addIndexesNoOptimize work like this?
Hi guys:
Running into a question with IndexWriter.addIndexesNoOptimize:
I am trying to expand a smaller index by replicating it into a larger
index. So I am adding the same directory N times.
I get an exception because noDupDirs(dirs) fails. For this call, is this
check neccessary?
Thanks Mike, I'm still on 2.3.1, so will upgrade soon.
Antony
Michael McCandless wrote:
This was an attempt on addIndexesNoOptimize's part to "respect" the
maxMergeDocs (which prevents large segments from being merged) you had
set on IndexWriter.
However, the check was too pedantic, and was
This was an attempt on addIndexesNoOptimize's part to "respect" the
maxMergeDocs (which prevents large segments from being merged) you had
set on IndexWriter.
However, the check was too pedantic, and was removed as of 2.4, under
this issue:
https://issues.apache.org/jira/browse/LUCENE
The javadocs state
"This requires ... and the upper bound* of those segment doc counts not exceed
maxMergeDocs."
Can one of the gurus please explain what that means and what needs to be done to
find out whether an index being merged fits that criteria.
Thanks
Antony
18 matches
Mail list logo
