Hi,
On 2019-12-16 18:58:36 -0500, Tom Lane wrote:
> Andres Freund <andres@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