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.
