> 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. Is your patch improving on that by also deduplicating the context? (I haven't had the time to closely look at your patch.) >> If that's the case we could alternatively do it manually and provide >> some getter macros. > > Possible, yes, but at the cost of (possibly) large code changes to > migrate to the new macros or inline functions, from direct field > accesses. > Whilst I do think saving bytes is worth something, I don't think we > should be shaving bytes down at the cost of readability and/or > backpatchability, especially when it's "just" a few bytes per > relation. Even with 100s of 1000s of relations that'll "just" be a few > MBs. Agreed. -- David Geier
