Re: Reducing relcache memory usage: deduping index shapes

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