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
