Horton

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

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
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:05:44Z
Lists: pgsql-hackers 
On Mon, May 17, 2021 at 01:48:03PM -0700, Andres Freund wrote:
> pg_attribute is one of the biggest table in a new cluster, and often the
> biggest table in production clusters. Its size is also quite relevant in
> memory, due to all the TupleDescs we allocate.
> 
> I just noticed that the new attcompression increased the size not just
> by 1 byte, but by 4, due to padding. While an increase from 112 to 116
> bytes isn't the end of the world, it does seem worth considering using
> existing unused bytes instead?

+1

FYI: attcompression was an OID until a few weeks before the feature was merged,
and there were several issues related to that:
  aa25d1089 - fixed two issues
  226e2be38

-- 
Justin

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