Re: Save a few bytes in pg_attribute - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: Save a few bytes in pg_attribute |
Date | |
Msg-id | 20230321174633.sbwfi6anwds3ipde@awork3.anarazel.de Whole thread Raw |
In response to | Re: Save a few bytes in pg_attribute (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Responses |
Re: Save a few bytes in pg_attribute
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Save a few bytes in pg_attribute (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) Re: Save a few bytes in pg_attribute (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
List | pgsql-hackers |
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
pgsql-hackers by date: