Hi,
On 2019-01-15 13:32:36 -0500, Tom Lane wrote:
> Well, we *had* an LRU mechanism for the catcaches way back when. We got
> rid of it --- see commit 8b9bc234a --- because (a) maintaining the LRU
> info was expensive and (b) performance fell off a cliff in scenarios where
> the cache size limit was exceeded. You could probably find some more info
> about that by scanning the mail list archives from around the time of that
> commit, but I'm too lazy to do so right now.
>
> That was a dozen years ago, and it's possible that machine performance
> has moved so much since then that the problems are gone or mitigated.
> In particular I'm sure that any limit we would want to impose today will
> be far more than the 5000-entries-across-all-caches limit that was in use
> back then. But I'm not convinced that a workload that would create 100K
> cache entries in the first place wouldn't have severe problems if you
> tried to constrain it to use only 80K entries.
I think that'd be true if you the accesses were truly randomly
distributed - but that's not the case in the cases where I've seen huge
caches. It's usually workloads that have tons of functions, partitions,
... and a lot of them are not that frequently accessed, but because we
have no cache purging mechanism stay around for a long time. This is
often exascerbated by using a pooler to keep connections around for
longer (which you have to, to cope with other limits of PG).
> As far as the relcache goes, we've never had a limit on that, but there
> are enough routine causes of relcache flushes --- autovacuum for instance
> --- that I'm not really convinced relcache bloat can be a big problem in
> production.
It definitely is.
> The plancache has never had a limit either, which is a design choice that
> was strongly influenced by our experience with catcaches.
This sounds a lot of having learned lessons from one bad implementation
and using it far outside of that situation.
Greetings,
Andres Freund
