Chris Hostetter wrote:
: But then the FieldCache is just starting to feel alot like column-stride
: fields
: (LUCENE-1231).
that's what i've been thinking ... my goal with LUCENE-831 was to make it
easier to manage FieldCache and hopefully the norms[] as well particularly
in the case of reopen
: But then the FieldCache is just starting to feel alot like column-stride
: fields
: (LUCENE-1231).
that's what i've been thinking ... my goal with LUCENE-831 was to make it
easier to manage FieldCache and hopefully the norms[] as well particularly
in the case of reopen ... but with column-str
Ahh woops sorry I didn't look at the latest patch on LUCENE-831 just
yet. Thanks! That's great.
Mike
Mark Miller wrote:
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
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
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 IndexR
Yeah, yeah, you are def right...if you have field caches larger than
your RAM, you can def spill off to HD. I just wonder if your going to
get performance that is acceptable if you are actually using all of
those fieldcaches and have to go to disk a lot. It would be awesome to
know how that works t
The obstacle I'm seeing is that I have a lot of fields which use sorting.
Sooner or later this will give an OutOfMem-error since the field-cache grows
too large. Am i correct in assuming that implementing for instance a EHCache
with flush-to-disk would solve this issue? (With a tradeoff for perfo
It does not specifically incorporate caching to disk, but what it does
do is easily allow you to provide a new Cache implementation. The
default implementation is just a simple in memory Map, but its trivial
to provide a new implementation using something like EHCache to back the
Cache implementati
I've seen some recent activity on LUCENE-831 "Complete overhaul of FieldCache
API" and read that it must be able to cleanly patch to trunk (haven't tried
yet).
What I'd like to know from people involved is if this patch incorporates
offloading of fieldcache to disk, or if this hasn't yet been ta
