"Yonik Seeley" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
