Re: Save a few bytes in pg_attribute

On 21.03.23 18:46, Andres Freund wrote:
>> 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?

Here is an updated patch that handles those three fields, including some
overflow checks. I also changed coninhcount to match attinhcount.

I structured the inhcount overflow checks to be independent of the
integer size, but maybe others find this approach weird.

Given the calculation shown, there is no value in reducing all three
fields versus just two, but I don't find compelling reasons to leave out
one or the other field. (attstattarget got the most discussion, but
that one is actually the easiest part of the patch.)

I took another hard look at some of the other proposals, including
moving some fields to the variable length part or combining some bool or
char fields. Those changes all appear to have a really long tail of
issues all over the code that I wouldn't want to attack them now in an
ad hoc way.

My suggestion is to use this patch and then consider the column
encryption patch as it stands now.

The discussion about attcacheoff seems to be still ongoing. But it
seems whatever the outcome would be independent of this patch: Either we
keep it or we remove it; there is no proposal to resize it.