On Wed, Nov 29, 2017 at 11:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The thing that makes me uncomfortable about this is that we used to have a
> catcache size limitation mechanism, and ripped it out because it had too
> much overhead (see commit 8b9bc234a). I'm not sure how we can avoid that
> problem within a fresh implementation.
At the risk of beating a dead horse, I still think that the amount of
wall clock time that has elapsed since an entry was last accessed is
very relevant. The problem with a fixed maximum size is that you can
hit it arbitrarily frequently; time-based expiration solves that
problem. It allows backends that are actively using a lot of stuff to
hold on to as many cache entries as they need, while forcing backends
that have moved on to a different set of tables -- or that are
completely idle -- to let go of cache entries that are no longer being
actively used. I think that's what we want. Nobody wants to keep the
cache size small when a big cache is necessary for good performance,
but what people do want to avoid is having long-running backends
eventually accumulate huge numbers of cache entries most of which
haven't been touched in hours or, maybe, weeks.
To put that another way, we should only hang on to a cache entry for
so long as the bytes of memory that it consumes are more valuable than
some other possible use of those bytes of memory. That is very likely
to be true when we've accessed those bytes recently, but progressively
less likely to be true the more time has passed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
