If you have many deletes on the index (not typical for a time-based index)
then forceMerge (or just forceMergeDeletes) will reclaim disk space.
Fewer file handles will be needed to open the index.
Some searches may be faster, but you should test in your case if that's
really the case. Much progr
It's odd that optimize is creating such tiny segments, and then that
these tiny segments wind up consuming so much disk space.
Can you turn on IndexWriter's infoStream, and post the output of the
attempts to optimize?
Are you sure there are no unhandled exceptions being logged to the
sy
There is not enough information here to even guess
at an answer. Please post the stack trace and any
other relevant information you can think of and maybe
there'll be some useful pointers people can give.
Best
Erick
On Mon, Feb 2, 2009 at 7:21 PM, Scott Smith wrote:
> I'm optimizing a database a
Lucene implements ACID (like modern databases), with the restriction
that only one transaction may be open at a time.
So, once commit (your step 4) is called and succeeds, Lucene
guarantees that any prior changes (eg your step 2) are written to
stable storage and will not be lost ("durability").
On 10/17/07, Melanie Langlois <[EMAIL PROTECTED]> wrote:
> From a different post I've read on this mailing list, I thought by letting
> this default the optimization will be done automatically every 10 documents
> added to the index (and then every 10 segments, they should be merges..). But
> fo
Ok,
I found some of my answers looking more into the code, I can actually print the
merging infos settings up the IndexWriter.setInfoStream ..
But there is still some stuff I don't get regarding the index optimization
process, I'm don't understand where the merging of document is done by default
10 maj 2007 kl. 21.29 skrev Yonik Seeley:
On 5/10/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
Deleted documents are removed on segment merges (for documents marked
as deleted in those segments).
Of course, that doesn't have to be the case. It would be a trivial
change to merge segments and
On 5/10/07, karl wettin <[EMAIL PROTECTED]> wrote:
> Deleted documents are removed on segment merges (for documents marked
> as deleted in those segments).
> Due to the nature of an inverted index, it's impossible w/o going over
> the complete index looking for all references to that docid.
Wha
10 maj 2007 kl. 21.28 skrev Yonik Seeley:
Deleted documents are removed on segment merges (for documents marked
as deleted in those segments).
Due to the nature of an inverted index, it's impossible w/o going over
the complete index looking for all references to that docid.
What about alte
Of course, that doesn't have to be the case. It would be a trivial
change to merge segments and not remove the deleted docs. That
usecase could be useful in conjunction with ParallelReader.
If the behavior of deleted docs during merging or optimization ever changes,
please make this configurab
On 5/10/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
Deleted documents are removed on segment merges (for documents marked
as deleted in those segments).
Of course, that doesn't have to be the case. It would be a trivial
change to merge segments and not remove the deleted docs. That
usecase co
On 5/10/07, karl wettin <[EMAIL PROTECTED]> wrote:
I really want to use document numbers as a secondary key in my object
storage. If I got it all right, the main problem is deleted documents
and optimization. Are there any other issues?
Deleted documents are removed on segment merges (for docum
l Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 05, 2005 9:27 AM
To: java-user@lucene.apache.org
Subject: Re: Optimization
On Oct 5, 2005, at 9:05 AM, Aigner, Thomas wrote:
Have a question.. Is there any obvious things that can be done
to help speed up
Tokens created:
mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 05, 2005 9:27 AM
To: java-user@lucene.apache.org
Subject: Re: Optimization
On Oct 5, 2005, at 9:05 AM, Aigner, Thomas wrote:
> Have a question.. Is there any obvious things that can be done
> to help speed up
On Oct 5, 2005, at 9:05 AM, Aigner, Thomas wrote:
Have a question.. Is there any obvious things that can be done
to help speed up query lookups especially wildcard searches (i.e.
*lamps).
Obvious? Sort of. *lamps needs to scan through _every_ single term
in the index (for the specified
15 matches
Mail list logo
