On Fri, 17 Feb 2023 at 16:40, Andres Freund <and...@anarazel.de> wrote: > I'd like a workload that hits a perf issue with this, because I think there > likely are some general performance improvements that we could make, without > changing the initial size or the "growth rate".
I didn't hear it mentioned explicitly here, but I suspect it's faster when increasing the initial size due to the memory context caching code that reuses aset MemoryContexts (see context_freelists[] in aset.c). Since we reset the context before caching it, then it'll remain fast when we can reuse a context, provided we don't need to do a malloc for an additional block beyond the initial block that's kept in the cache. Maybe we should think of a more general-purpose way of doing this caching which just keeps a global-to-the-process dclist of blocks laying around. We could see if we have any free blocks both when creating the context and also when we need to allocate another block. I see no reason why this couldn't be shared among the other context types rather than keeping this cache stuff specific to aset.c. slab.c might need to be pickier if the size isn't exactly what it needs, but generation.c should be able to make use of it the same as aset.c could. I'm unsure what'd we'd need in the way of size classing for this, but I suspect we'd need to pay attention to that rather than do things like hand over 16MBs of memory to some context that only wants a 1KB initial block. David
