On Mon, Nov 16, 2015 at 5:08 PM, Todd Long <lon...@gmail.com> wrote: > Mikhail Khludnev wrote > > "External merge" join helps to avoid boilerplate caching in such simple > > cases. > > Thank you for the reply. I can certainly look into this though I would have > to apply the patch for our version (i.e. 4.8.1). I really just simplified > our data configuration here which actually consists of many sub-entities > that are successfully using the SortedMapBackedCache cache. I imagine this > would still apply to those as the queries themselves are simple for the > most > part.
It's worth to mention that for really complex relations scheme it might be challenging to organize all of them into parallel ordered streams. > I assume performance-wise this would only require the single table > scan? > It sounds like that. But I'm an expert to comment in precise terms. > > I'm still very much interested in resolving this Berkley database cache > issue. I'm sure there is some minor configuration I'm missing that is > causing this behavior. Again, I've had no issues with the > SortedMapBackedCache for its caching purpose... I've tried simplifying our > data configuration to only one thread with a single sub-entity with the > same > results. Again, any help would be greatly appreciated with this. > threads... you said? Which ones? Declarative parallelization in EntityProcessor worked only with certain 3.x version. > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/DIH-Caching-w-BerkleyBackedCache-tp4240142p4240356.html > Sent from the Solr - User mailing list archive at Nabble.com. > -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics <http://www.griddynamics.com> <mkhlud...@griddynamics.com>
