Hi, On 2019-12-16 18:58:36 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > But what if we had a new type of memory context that did not itself > > manage memory underlying allocations, but instead did so via the parent? > > If such a context tracked all the live allocations in some form of list, > > it could then free them from the parent at reset time. In other words, > > it'd proxy all memory management via the parent, only adding a separate > > name, and tracking of all live chunks. > > I dunno, that seems like a *lot* of added overhead, and opportunity for > bugs.
What kind of bugs are you thinking of? > Maybe it'd be all right for contexts in which alloc/dealloc is > very infrequent. I don't think the overhead would be enough to matter even for moderaly common cases. Sure, another 16bytes of overhead isn't free, nor is the indirection upon allocation/free, but it's also not that bad. I'd be surprised if it didn't turn out to be cheaper in a lot of cases, actually, due to not needing a separate init block etc. Obviously it'd make no sense to use such a context for cases with very frequent allocations (say parsing, copying a node tree), or where bulk deallocations of a lot of small allocations is important - but there's plenty other types of cases. > But why not just address this problem by reducing the allocset > blocksize parameter (some more) for these index contexts? Well, but what would we set it to? The total allocated memory sizes for different indexes varies between ~1kb and 4kb. And we'll have to cope with that without creating waste again. We could allow much lower initial and max block sizes for aset, I guess, so anything large gets to be its own malloc() block. > I'd even go a bit further, and suggest that the right way to exploit > our knowledge that these contexts' contents don't change much is to > go the other way, and reduce not increase their per-chunk overhead. Yea, I was wondering about that too. However, while there's also a good number of small allocations, a large fraction of the used space is actually larger allocations. And using a "alloc only" context doesn't really address the fact that the underlying memory blocks are quite wasteful - especially given that this data essentially lives forever. For the specific case of RelationInitIndexAccessInfo(), allocations that commonly live for the rest of the backend's life and are frequent enough of them to matter, it might be worth micro-optimizing the allocations. E.g. not doing ~7 separate allocations within a few lines... Not primarily because of the per-allocation overheads, but more because that'd allow to size things right directly. Greetings, Andres Freund
