Andres Freund <and...@anarazel.de> writes:
> On 2019-03-13 16:50:53 -0400, Robert Haas wrote:
>> On Wed, Mar 13, 2019 at 4:38 PM Robert Haas <robertmh...@gmail.com> wrote:
>>> On Wed, Mar 13, 2019 at 4:18 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>>>> Off topic for the moment, since this clearly wouldn't be back-patch
>>>> material, but I'm starting to wonder if we should just have a context
>>>> for each relcache entry and get rid of most or all of the retail
>>>> cleanup logic in RelationDestroyRelation ...
>> It just occurred to me that one advantage of this would be that you
>> could see how much memory was being used by each relcache entry using
>> MemoryContextStats(), which seems super-appealing.
> But it might also make it frustrating to look at memory context dumps -
> we'd suddenly have many many more memory context lines we'd displayed,
> right? Wouldn't that often make the dump extremely long?
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.
My gut feeling is that right now relcache entries tend to be mas-o-menos
the same size, except for stuff that is *already* in sub-contexts, like
index and partition descriptors. So I'm not that excited about this
adding useful info to context dumps. I was just looking at it as a way
to make relcache entry cleanup simpler and less leak-prone.
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. You could imagine per-catcache contexts, too.
The main limiting factor here is that the per-context overhead could get
excessive.
regards, tom lane
