Re: Separate memory contexts for relcache and catcache

On Tue, Nov 26, 2024 at 4:10 PM Rahila Syed <rahilasyed90(at)gmail(dot)com> wrote:

>
>
> Having reviewed the discussion regarding potential fragmentation issues
> caused by
> creating a large number of new contexts in each backend, I would like to
> take a step
> back and better understand the motivation behind separating these contexts.
>
> IIUC, segregating cache memory allocations into RelCacheContext and
> CatCacheContext
> allows for grouping a large number of memory allocations under a
> common 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