Hi, On 2019-01-18 19:57:03 -0500, Robert Haas wrote: > On Fri, Jan 18, 2019 at 4:23 PM and...@anarazel.de <and...@anarazel.de> wrote: > > My proposal for this was to attach a 'generation' to cache entries. Upon > > access cache entries are marked to be of the current > > generation. Whenever existing memory isn't sufficient for further cache > > entries and, on a less frequent schedule, triggered by a timer, the > > cache generation is increased and th new generation's "creation time" is > > measured. Then generations that are older than a certain threshold are > > purged, and if there are any, the entries of the purged generation are > > removed from the caches using a sequential scan through the cache. > > > > This outline achieves: > > - no additional time measurements in hot code paths > > - no need for a sequential scan of the entire cache when no generations > > are too old > > - both size and time limits can be implemented reasonably cheaply > > - overhead when feature disabled should be close to zero > > Seems generally reasonable. The "whenever existing memory isn't > sufficient for further cache entries" part I'm not sure about. > Couldn't that trigger very frequently and prevent necessary cache size > growth?
I'm thinking it'd just trigger a new generation, with it's associated "creation" time (which is cheap to acquire in comparison to creating a number of cache entries) . Depending on settings or just code policy we can decide up to which generation to prune the cache, using that creation time. I'd imagine that we'd have some default cache-pruning time in the minutes, and for workloads where relevant one can make sizing configurations more aggressive - or something like that. Greetings, Andres Freund
