Hi, On 2024-10-29 15:00:02 -0700, Jeff Davis wrote: > On Wed, 2024-04-03 at 16:12 +0300, Melih Mutlu wrote: > > Rebased. PSA. > > Thank you. I missed your patch and came up with a similar patch over > here: > > https://www.postgresql.org/message-id/flat/78599c442380ddb5990117e281a4fa65a74231af.ca...@j-davis.com > > I closed my thread and we can continue this one. > > One difference is that I tried to capture almost all uses of > CacheMemoryContext so that it would become just a parent context > without many allocations of its own.
I'm a bit worried about the increase in "wasted" memory we might end up when creating one aset for *everything*. Just splitting out Relcache and CatCache isn't a big deal from that angle, they're always used reasonably much. But creating a bunch of barely used contexts does have the potential for lots of memory being wasted at the end of a page and on freelists. It might be ok as far was what you proposed in the above email, I haven't analyzed that in depth yet. > I agree with others that we should look at changing the initial size or > type of the contexts, but that should be a separate commit. It needs to be done close together though, otherwise we'll increase the new-connection-memory-usage of postgres measurably. I've previously proposed creating a type of memory context that's intended for places where we never expect to allocate much which allocates from either a superior memory context or just from the system allocator and tracks memory via linked lists. That'd allow us to use fairly granular memory contexts with low overhead, which we e.g. could use to actually create each catcache & relcache entry in its own context. One concern that was voiced about that idea was that it'd perform badly if such a context did end up being used hotly - I'm not sure that's a real problem, but we could address it by switching to a different allocation scheme once a certain size is reached. Greetings, Andres Freund
