Morus, that description of 3 sets of index files is what I was imagining, too. I'll have to test and add to the book errata, it seems.
Thanks for the info, Otis --- Morus Walter <[EMAIL PROTECTED]> wrote: > Otis Gospodnetic writes: > > Hello, > > > > Yes, that is how optimize works - copies all existing index > segments > > into one unified index segment, thus optimizing it. > > > > see hit #1: > http://www.lucenebook.com/search?query=optimize+disk+space > > > > However, three times the space sounds a bit too much, or I make a > > mistake in the book. :) > > > I cannot explain why, but ~ three times the size of the final index > is > what I observed, when I logged disk usage during optimize of an index > in compound index format. > The test was on linux, I simply did a 'du -s' every few seconds > parallel > to the optimize. > I didn't test noncompund format. Probably optimizing a compund format > requires to store the different parts of the compound file separately > before joining them to the compound file (sound reasonable, otherwise > you would need to know the sizes before creating the parts). In that > case > you had the original index, the separate files and the new compound > file > as the disk usage peak. > > So IMHO the book is wrong. > > Morus > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
