lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless" <luc...@mikemccandless.com>
Subject Re: [jira] Updated: (LUCENE-843) improve how IndexWriter uses RAM to buffer added documents
Date Fri, 23 Mar 2007 15:16:41 GMT

"Yonik Seeley" <yonik@apache.org> wrote:
> > We say that
> > developers should not rely on docIDs but people still seem to rely on
> > their monotonic ordering (even though they change).
> 
> Yes.  If the benefits of removing that guarantee are large enough, we
> could consider dumping it... but not in Lucene 2.x IMO.  We should see
> how people are using this, and if there are acceptable workarounds.
> Solr's current dependence on document ordering could me removed.

I don't think we should change this "feature" of the current merge
policy.  I think it may break too many people in hard-to-figure-out
ways.  It's also not clear that we have much to gain if we were
allowed to break this?  (The current "logarithmic" merge policy I
think works quite well.)

And as Steve said, once merge policy is decoupled from the writer then
apps have the freedom to pick or build a different merge policy
(leaving current one as the default).

However, I do think we should fix the bug with the current merge
policy when you "flush by RAM" (LUCENE-845).  Since the recommended
way (I think?) to maximize indexing performance is to "flush by RAM
usage" I expect people will start hitting this bug fairly often.

Mike

---------------------------------------------------------------------
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