"Doron Cohen" <[EMAIL PROTECTED]> wrote: > Hi Mike, > > "Michael McCandless" <[EMAIL PROTECTED]> wrote on 24/09/2007 > 20:19:31: > > > But, we have to be careful for the ParallelReader use case: for this > > case you only want to trigger flushing by doc count (ie, never by > > RAM), right? >
> I think you mean the case that applications using the ParallelReader > need full control over flushing, so they can do all the tricks with > docids, right? Right. It's actually merging that you need control over (since it's only merging that shifts the docIDs), but one simple way to control merging is to always flush at the same time. > > It seems like sometimes we want "A or B, whichever comes first" > > but other times either just "A" or just "B". > > Is it perhaps more drastic? - some applications need a way to > disable some (or all) auto flush mechanisms? Could a > DISABLE_AUTU_FLUSH = -1 be used as an indication to disable certain > flushing? I.e. if passed to setMaxBuffDocs will disable auto > flushing by number of buffered docs, if passed to setMaxRamBytes > would disable that type of flushing, etc.? I like this approach -- assigning a static constant so people can separately turn off the different sources of flush triggering. Then whether we use MAX_INT (Ning's suggestion) or -1, it's got a name (DISABLE_AUTO_FLUSH). Maybe -1 is better since that's cleaner for double & int types. On flushing pending deletes by RAM usage: should we just bundle this up under "flush by RAM usage"? Ie "when total RAM usage, either from buffered deletes, buffered docs, anything else, exceeds X then it's time to flush"? (Instead of having a separate "max RAM usage for buffered deletes" trigger). Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
