Hi,
On 2019-03-13 17:10:55 -0400, Tom Lane wrote:
> There's already a mechanism in there to suppress child contexts after
> 100 or so, which would almost inevitably kick in on the relcache if we
> did this. So I don't believe we'd have a problem with the context dumps
> getting too long --- more likely, the complaints would be the reverse.
Well, that's two sides of the same coin.
> Having said that, I do agree that CacheMemoryContext is too much of an
> undifferentiated blob right now, and splitting it up seems like it'd be
> good for accountability. I'd definitely be +1 for a catcache vs. relcache
> vs. other caches split.
That'd make a lot of sense.
> You could imagine per-catcache contexts, too.
> The main limiting factor here is that the per-context overhead could get
> excessive.
Yea, per relcache entry contexts seem like they'd get really expensive
fast. Even per-catcache seems like it might be noticable additional
overhead for a new backend.
Greetings,
Andres Freund
