Re: Reducing relcache memory usage: deduping index shapes

Hi!

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

Here are a few more things we could do to shrink the size of RelationData:

1. Pack ten bool members into a bitmask and add some convience getter
inline functions. Saves ~8 bytes.

2. rd_index can be derived from rd_indextuple. Saves 8 bytes.

3. I didn't dig too deep but it seems to me that the members from
rd_lockInfo can be also derived: rel_id == rd_id and dbId ==
MyDatabaseId. Saves 8 bytes.

3. Split members by relation type: two disjoint groups of fields are
always NULL depending on whether the entry is a table or an index:

Index only (~128 bytes):

rd_index, rd_indextuple, rd_indexcxt, rd_indam, rd_opfamily,
rd_opcintype, rd_support, rd_supportinfo, rd_indoption, rd_indexprs,
rd_indpred, rd_exclops, rd_exclprocs, rd_exclstrats, rd_indcollation,
rd_opcoptions

Table only (~170 bytes):

rd_rules, rd_rulescxt, trigdesc, rd_rsdesc, rd_fkeylist, rd_fkeyvalid,
rd_partkey*, rd_partdesc*, rd_partcheck*, rd_keyattr, rd_pkattr,
rd_idattr, rd_hotblockingattr, rd_summarizedattr, rd_pubdesc, rd_fdwroutine

We could put these members into their own struct and replace each group
with a single lazily-allocated pointer to the corresponding struct,
depending on the relation type.

By packing the struct and additionally doing these changes we would
roughly half the size of RelationData. Unfortunately, all of these
changes would require patching a lot of usage sites.

--
David Geier