Right...that is what the latest patch I put up does (Hoss basically stubbed it all out to be ready for this).
Each SegmentReader has its own cache. Each MultiReader can have its own cache as well (in the case that you want a primitive array), but if you can take an ObjectArray object instead, the MultiReader returns an ObjectArray that distributes doc i requests to the appropriate ObjectArray owned by a SegmentReader (the ObjectArray returned from the SegmentReaders cache). This was done by your suggestion :) And man is it fast in some cases. It works amazing well if you reopen a lot and have a lax merge factor...just as you say, often you only have to load a tiny new segment when reloading the field cache...on average its tons faster to reopen. - Mark On Thu, 2008-04-17 at 14:54 -0400, Michael McCandless wrote: > Mark Miller wrote: > > > I think your 2 readers question is interesting and I will certainly > > think about it. Right now though, each IndexReader instance holds > > it own > > cache. I'll have to dig back into the code and see about possibly > > keying > > on the directory or something? > > I think, with how IndexReader.reopen() now works, we should switch to > somehow having the FieldCache "attached" to each SegmentReader instead > of stored globally keyed by the top MultiSegmentReader. > > This way if we do a reopen and say the only change to the index was 10 > added docs then the only new FieldCache that gets created is that > length 10 array (because only that SegmentReader will be new). > > But then the FieldCache is just starting to feel alot like column- > stride fields > (LUCENE-1231). > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
