On Fri, Mar 6, 2020 at 1:04 AM Aadithya C <aadithy...@gmail.com> wrote: > > In my personal opinion, there are a few advantages of resizing - > > > 1) The size of the cache is unpredictable as there is a fixed(guesstimate) > accounting for the key size. With a resizable cache, we can potentially > cache heavier queries and exploratively resize the cache when faced with > memory pressure. > > > 2) With a resizable cache, we can control memory allocation dynamically > based on the workload. For a large cache, dropping the entire cache when we > want to reallocate some memory seems like an excessive action. > > > 3) The query cache effectiveness is very workload dependent. I have > observed the cache hit-rate can be in single digits for certain workloads > and memory can be effectively used elsewhere.
When you say resizing, do you mean only increasing sizes or decreasing as well? IMO, this would require defining a model for on demand eviction until the cache reaches a target size (be mindful of what happens to incoming caching requests in that period). A potentially large downsizing request can lead to a large eviction time -- not sure what impact it would have on query performance. I would agree with Adrien's suggestion of using a new cache unless you have a very compelling reason not to. Even then, I would be wary of muddying LRUQueryCache's waters -- you might want to create your own custom derivative of it? Atri -- Regards, Atri Apache Concerted --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
