Earwin: LogMergePolicy.getUseCompoundFile() is a public and not private API on trunk, not deprecated and used. Perhaps you are talking about something else?
I'm aware of LUCENE-2773, but still, if you look at LMP's getUseCompoundFile() in trunk, you'll see it does not factor in the noCFSRatio setting. It always returns 'useCompoundFile'. Shai On Thu, Dec 2, 2010 at 1:28 PM, Simon Willnauer < simon.willna...@googlemail.com> wrote: > On Thu, Dec 2, 2010 at 12:14 PM, Michael McCandless > <luc...@mikemccandless.com> wrote: > > On Thu, Dec 2, 2010 at 4:43 AM, Simon Willnauer > > <simon.willna...@googlemail.com> wrote: > > > >> During the work on Column Stride Fields I was actually thinking that > >> Compound vs. Non-Compound should not be a global decision since we now > >> have codecs and each codec should use its own way of writing files. > >> Maybe it would make things way easier if we expose CFS to codecs and > >> let them decide what to do. I can imagine that I want to use CFS for > >> some of the codecs like Column Stride or fields that are not used for > >> searches but keep individual files per codec. Just an idea.... > > > > +1! > > > > This would be a nice simplification. > > I created an issue for this: LUCENE-2789 > > > simon > > > > EG, it's bizarre today that on flushing a new segment, which has > > nothing to do with merging, we consult the MP to decide if we need CFS > > or not. > > > > Also, it's awkward we have getCF and also getCFDocStore. In the > > future (docvalues) we may also want to separately build CFS for those > > files, or not. > > > > Making all these decisions private to the codec makes great sense. > > It's then free to CFS however it wants to. But, the codec would need > > wider context, I think the full SegmentInfos, to base its decision on. > > EG, LMP now conditionally builds CFS only if the segment is > > "smallish" relative to total index size. > > > > Mike > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
