Re: Reducing relcache memory usage: deduping index shapes

On Wed, 2 Sept 2026 at 10:06, David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
>
>> Because indexes allocate an array of nkeyatts * indam->amsupport
>> FmgrInfos, which for some index shapes can result in huge allocations
>> (BRIN: 15, GiST: 12, btree: 6). There is certainly space for further
>> optimization in other places, but this required changes in fewer code
>> areas than if I'd started changing the data types and shape of
>> Relation itself, given the spread of Relation across the codebase.
>
> I see.

Yep. That's anywhere from 288 bytes to 720 bytes per key attribute.
It's easy to see how that can impact the total session memory usage by
a significant amount, especially when combined with small aset
contexts' allocated-size rounding and block allocations.

>>> One more micro optimization that we could do is better packing
>>> RelationData. On my AMD64 system sizeof(RelationData) == 488 bytes. By
>>> reordering the members we could get it down to 440 bytes which is about
>>> 10% savings.
>>
>> Yeah, packing RelationData would save some in struct size, but given
>> that these are mostly still allocated as separate allocations in an
>> aset context, shaving bytes off of RelationData won't help much until
>> we get below 256 bytes. I would love to get the struct size that far
>> down, but I don't expect that to be achievable with the current
>> contents of the struct.
>>
>> I've considered allocating Relations in a slab context to avoid aset's
>> alignment overhead, but never got far enough with a prototype to get
>> it to pass all tests.
>
> With the other optimizations from [1] we should be able to get below 256
> bytes. If you want I can give this a try.

Back-of-the-envelope calculation: Currently, RelationData is 488
bytes, of which 50 wasted on alignment (so, 48 bytes recoverable). If
we somehow get the index and table fields to not be used at the same
time, we'd gain another 128 bytes (because the larger of the two must
remain). This leaves us with 312 bytes, which is still 56 bytes over
the target, and I don't think we can trivially find 7 pointers' worth
of fields to remove.

But, feel free to try.

- Matthias