Re: Separate memory contexts for relcache and catcache - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Separate memory contexts for relcache and catcache
Date
Msg-id CAKU4AWrjsTp_BxG4WDYjTwY95syq7dfOKP2NpHRVSeFcEKPDbQ@mail.gmail.com
Whole thread Raw
In response to Separate memory contexts for relcache and catcache  (Melih Mutlu <m.melihmutlu@gmail.com>)
List pgsql-hackers


Most catcache and relcache entries (other than index info etc.) currently go straight into CacheMemoryContext. And I believe these two caches can be the ones with the largest contribution to the memory usage of CacheMemoryContext most of the time. For example, in cases where we have lots of database objects accessed in a long-lived connection, CacheMemoryContext tends to increase significantly.

While I've been working on another patch for pg_backend_memory_contexts view, we thought that it would also be better to see the memory usages of different kinds of caches broken down into their own contexts. The attached patch implements this and aims to easily keep track of the memory used by relcache and catcache


+ 1 for the idea, this would be pretty useful as a proof of which
context is consuming most of the memory and it doesn't cost
much.  It would be handy than estimating that by something 
like select count(*) from pg_class. 

I think, for example,  if we find relcache using too much memory,
it is a signal that the user may use too many partitioned tables. 


--
Best Regards
Andy Fan

pgsql-hackers by date:

Previous
From: Melih Mutlu
Date:
Subject: Separate memory contexts for relcache and catcache
Next
From: Robert Haas
Date:
Subject: Re: initial pruning in parallel append