Re: Reducing relcache memory usage: deduping index shapes

On Thu, 3 Sept 2026 at 18:02, David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
>
>>>> 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.
>
> I've managed to crunch sizeof(RelationData) down to 256 bytes and
> there's some more room for improvement, see below. Attached is the patch
> set. It passes tests.

That's cool. I'm not fully on board with all the techniques you
applied, but it does seem like some of these can be useful. If you're
up to getting this from POC to a workable state, please start a
separate thread with its own CF entry, then we can discuss over there.

I think allocating the relcache Relations in a slab context would help
reduce memory usage whenever we shave bytes off, vs aset's hard
power-of-two barriers.

> 1) Change all the arrays of length nkeys to a single array of structs.
> That would save a bunch of pointers in the index union elg. It's not
> clear though if that might regress performance somewhere because of
> cache locality but would be worth a try.
>
> 2) Put rules and trigger related members into separately allocated
> structured referenced by a single pointer. These members are rarely used
> and shouldn't be performance critical.
>
> 3) Pack booleans into bitfield.

My experience with bitfields is that they're not optimized very well
by compilers, so I'd like to avoid using bitpacking whenever possible.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)