Andres Freund <andres@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.
Maybe you could make it work on the basis of number of cache accesses,
or some other normalized-to-workload-not-wall-clock time reference.
regards, tom lane