Re: Reducing relcache memory usage: deduping index shapes

On Tue, 8 Sept 2026 at 17:30, David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
>> 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.
>
> Yes, especially as long as RelationData is so big. The next smaller
> allocation size is 128 bytes. Until then shaving off more bytes doesn't
> truly save anything with ASET. But I'm also not sure how much we can
> truly still get rid of without causing more indirections which are
> bad for performance.
>
> Any idea why ASET doesn't have more fine grained allocation classes?

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.

>>> 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.
>
> 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.

Kind regards,

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