On 2017-12-01 16:40:23 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-12-01 16:20:44 -0500, Robert Haas wrote: > >> Well, yeah, that would be insane. But I think even something very > >> rough could work well enough. I think our goal should be to eliminate > >> cache entries that are have gone unused for many *minutes*, and > >> there's no urgency about getting it to any sort of exact value. For > >> non-idle backends, using the most recent statement start time as a > >> proxy would probably be plenty good enough. Idle backends might need > >> a bit more thought. > > > Our timer framework is flexible enough that we can install a > > once-a-minute timer without much overhead. That timer could increment a > > 'cache generation' integer. Upon cache access we write the current > > generation into relcache / syscache (and potentially also plancache?) > > entries. Not entirely free, but cheap enough. In those once-a-minute > > passes entries that haven't been touched in X cycles get pruned. > > I have no faith in either of these proposals, because they both assume > that the problem only arises over the course of many minutes. In the > recent complaint about pg_dump causing relcache bloat, it probably does > not take nearly that long for the bloat to occur.
To me that's a bit of a different problem than what I was discussing here. It also actually doesn't seem that hard - if your caches are growing fast, you'll continually get hash-resizing of the various. Adding cache-pruning to the resizing code doesn't seem hard, and wouldn't add meaningful overhead. Greetings, Andres Freund
