Re: Move pg_attribute.attcompression to earlier in struct for reduced size? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date
Msg-id YKMXVHCoNGZ61E9q@paquier.xyz
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Andres Freund <andres@anarazel.de>)
Responses Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
List 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: "ERROR: deadlock detected" when replicating TRUNCATE
Next
From: "Pengchengliu"
Date:
Subject: RE: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump