Re: Save a few bytes in pg_attribute

Hi,

On 2023-03-21 18:15:40 +0100, Peter Eisentraut wrote:
> On 21.03.23 17:43, Andres Freund wrote:
> > > The context of my message was to do the proposed change for PG16 to buy back
> > > a few bytes that are being added by another feature
> > How much would you need to buy back to "reach parity"?
>
> I don't think we can find enough to make the impact zero bytes. It's also
> not clear exactly what the impact of each byte would be (compared to
> possible complications in other parts of the code, for example). But if
> there are a few low-hanging fruit, it seems like we could pick them, to old
> us over until we have a better solution to the underlying issue.

attndims 4->2
attstattarget 4->2
attinhcount 4->2

+ some reordering only gets you from 112->108 unfortunately, due to a 1 byte
alignment hole and 2 bytes of trailing padding.

before:
/* size: 112, cachelines: 2, members: 22 */
/* sum members: 111, holes: 1, sum holes: 1 */
/* last cacheline: 48 bytes */

after:
/* size: 108, cachelines: 2, members: 22 */
/* sum members: 105, holes: 1, sum holes: 1 */
/* padding: 2 */
/* last cacheline: 44 bytes */

You might be able to fill the hole + padding with your data - but IIRC that
was 3 4byte integers?

FWIW, I think we should consider getting rid of attcacheoff. I doubt it's
worth its weight these days, because deforming via slots starts at the
beginning anyway. The overhead of maintaining it is not insubstantial, and
it's just architecturally ugly to to update tupledescs continually.

Not for your current goal, but I do wonder how hard it'd be to make it work to
store multiple booleans as bitmasks. Probably ties into the discussion around
not relying on struct "mapping" for catalog tables (which we IIRC decided is
the sensible way the NAMEDATALEN restriction).

E.g. pg_attribute has 6 booleans, and attgenerated effectively is a boolean
too, and attidentity could easily be modeled as such as well.

If were to not rely on struct mapping anymore, we could possibly transparently
do this as part of forming/deforming heap tuples. Using something like
TYPALIGN_BIT. The question is whether it'd be too expensive to decode...

Greetings,

Andres Freund