Re: Separate memory contexts for relcache and catcache
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: Separate memory contexts for relcache and catcache |
| Дата | |
| Msg-id | CAExHW5vLRUk+9ZxF4FgaqdfmU2e8JbWES7ijhA0Bd6_bekr=Kw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Separate memory contexts for relcache and catcache (Melih Mutlu <m.melihmutlu@gmail.com>) |
| Список | pgsql-hackers |
On Tue, Nov 26, 2024 at 4:10 PM Rahila Syed <rahilasyed90@gmail.com> wrote:
Having reviewed the discussion regarding potential fragmentation issues caused bycreating a large number of new contexts in each backend, I would like to take a stepback and better understand the motivation behind separating these contexts.
IIUC, segregating cache memory allocations into RelCacheContext and CatCacheContextallows for grouping a large number of memory allocations under acommon context, which, in turn, aids in monitoring memory consumption. However,I believe this reasoning does not apply to SPICacheContext and PlanCacheContext,as these contexts do not have any allocations of their own.
How, then, does separating these contexts from CacheMemoryContext improve monitoring?
A query which accumulates statistics based on the (context) path prefix (path of PlanCacheContext or SPICacheContext) can be used to provide total memory allocated for plans. This will work even if we change the names of child context e.g. CachedPlanContext, CachedQueryContext or if we add more child contexts. Probably such a change is mostly unlikely. Whether that advantage is worth spending extra memory in fragmentation? Probably not. But I just wanted to note some use.
Best Wishes,
Ashutosh Bapat
В списке pgsql-hackers по дате отправления: