On Fri, Apr 3, 2009 at 5:32 PM, Jason Rutherglen <jason.rutherg...@gmail.com> wrote: >> meaning in Bobo you'd like to manage your own memory resident > field caches, and merge them whenever IW has merged a segment? > Seems like you don't need genealogy for that. > > Agreed, there is no need for full genealogy.
OK >> CSF isn't really designed yet. How come it can't be used with > Bobo's field caches? > > I guess CSF should be able to support it, makes sense. As long > as the container is flexible with the encoding (I need to look > into this more on the Bobo side). Well as CSF unfolds let's take Bobo's usage into account. >> Lucene's internal field cache usage is now entirely at the > segment level (ie, Lucene core should never request full field > cache array at the MultiSegmentReader level). I think Bobo must > have to do the same, if it handles near realtime updates, to get > adequate performance. > > Bobo needs to migrate to this model, I don't think we've done > that yet. Hmm OK. That's means reopen is very costly? >> EG how come Bobo made its own field cache impl? Just because > uninversion is too slow? > > It could be integrated once LUCENE-831 is completed. I think the > current model of a weak reference and the inability to unload if > needed is a concern. I don't think it's because of uninversion. Ahh OK. We know about that one (for LUCENE-831): the app should have control over the caching policy. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
