Ahh, right, I will update fileformats.xml & re-build html/PDF
(with Forrest 0.8) before committing.
The only downside I have now is if you do flush by RAM (which gives
best performance), you have to be very careful to work around
LUCENE-845 by also setting maxBufferedDocs to be something "around"
the right number. However this downside should go away once we
resolve LUCENE-845 (which is next on my stack, after the "multiple
writers over NFS" that's in progress now!).
I will also plant a tag just before committing.
Thanks for reviewing, everyone! I will give it another day or so and
then commit.
Mike
"Grant Ingersoll" <
gsingers@...> wrote:
> Mike,
>
> Nice piece of work here. One caveat, I think you mentioned you
> needed to update fileformats.xml (don't forget to generate the site
> and commit those changes too), but I don't see that in the patch.
>
> Also, do you see any downsides to this patch? Do you think it would
> ever be the case that a user would not benefit from it? If so,
> probably would be useful to document them.
>
> Other than that, I am +1
>
> Cheers,
> Grant
>
> 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.
> >
> > Given that it's such a big change I think (?) it's appropriate to ask
> > for a vote (only PMC member votes are binding) to make sure we have
> > consensus that this is net/net a good change for Lucene.
> >
> > Mike
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
java-dev-unsubscribe@...
> > For additional commands, e-mail:
java-dev-help@...
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
java-dev-unsubscribe@...
> For additional commands, e-mail:
java-dev-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
java-dev-unsubscribe@...
For additional commands, e-mail:
java-dev-help@...