Hi, On 2026-09-10 12:42:34 +0200, David Geier wrote: > > Performance, and memory overhead? > > Right now, we spend 88 of 200 bytes of the AllocSetContext itself on > > 11 freelists, and finer grained classes would mean larger freelists > > and larger overheads (assuming we don't want to shrink the current > > 8B-8kB range of freelist-supported chunk sizes). > > Additionally, powers of two are cheap to calculate vs arbitrary > > numbers, and this reduces the computational overhead and improves the > > branch-predictability of aset. > > I hadn't realized that we're creating tons of memory contexts in > RelationData, e.g. one per index. Beyond wasting memory this is also > cluttering pg_backend_memory_contexts considerably. > > I had a quick look if we can easily get rid of rd_indexcxt but there's > some memory from the function manager that is not directly referenced > and can only be implicitly freed by destroying rd_indexcxt.
I think that'd be the wrong direction. We shouldn't use fewer contexts, we should use vastly *more* contexts for the various caches. It's a real issue that today we a) can have leaks in CacheMemoryContext that cannot be attributed to anything b) can have huge memory usage in CacheMemoryContext - without leaks - without the ability to figure out why CacheMemoryContext is that big. > Is your patch improving on that by also deduplicating the context? (I > haven't had the time to closely look at your patch.) I would strenuously object if it did. I don't think cluttering pg_backend_memory_contexts is an argument, that needs to be addressed on the querying side. With the path support added a few releases back it's not that hard anymore. WRT memory overhead of the contexts: That's largely addressed by proxy context stuff. Greetings, Andres Freund
