Re: Reducing relcache memory usage: deduping index shapes

From: David Geier <geidav(dot)pg(at)gmail(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Reducing relcache memory usage: deduping index shapes
Date: 2026-09-08 15:30:29
Message-ID: 6db68318-7358-41b4-92c6-68e02677bf54@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Matthias!

>> 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.
Sounds good. Will do.
> 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?

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

--
David Geier

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-09-08 15:34:08 Re: Add pg_nodiscard decorations to Bitmapset functions
Previous Message Nathan Bossart 2026-09-08 15:24:59 Re: Speed up COPY FROM text/CSV parsing using SIMD