Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date: 2021-05-18 01:24:36
Message-ID: YKMXVHCoNGZ61E9q@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 17, 2021 at 02:28:57PM -0700, Andres Freund wrote:
> On 2021-05-17 17:06:32 -0400, Tom Lane wrote:
>> Putting it just after attalign seems like a reasonably sane choice
>> from the standpoint of grouping things affecting physical storage;
>> and as you say, that wins from the standpoint of using up alignment
>> padding rather than adding more.
>
> Makes sense to me.

+1.

>> Personally I'd think the most consistent order in that area would
>> be attbyval, attalign, attstorage, attcompression; but perhaps it's
>> too late to swap the order of attstorage and attalign.
>
> Given that we've put in new fields in various positions on a fairly
> regular basis, I don't think swapping around attalign, attstorage would
> cause a meaningful amount of additional pain. Personally I don't have a
> preference for how these are ordered.

If you switch attcompression, I'd say to go for the others while on
it. It would not be the first time in history there is a catalog
version bump between betas.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pengchengliu 2021-05-18 01:27:33 RE: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
Previous Message Peter Smith 2021-05-18 01:22:05 Re: "ERROR: deadlock detected" when replicating TRUNCATE