Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Dilip Kumar <dilipbalaut@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2021-05-17T21:06:32Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> If we moved attcompression to all the other bool/char fields, we'd avoid
> that size increase, as there's an existing 2 byte hole.

+1.  Looks to me like its existing placement was according to the good
old "add new things at the end" anti-pattern.  It certainly isn't
related to the adjacent fields.

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.

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.

			regards, tom lane

Commits

  1. Remove forced toast recompression in VACUUM FULL/CLUSTER

  2. Rethink definition of pg_attribute.attcompression.

  3. Fix memory leak when de-toasting compressed values in VACUUM FULL/CLUSTER

  4. Re-order pg_attribute columns to eliminate some padding space.

  5. Add more TAP tests for pg_dump with attribute compression