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: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, Dilip Kumar <dilipbalaut@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2021-05-27T04:11:38Z
Lists: pgsql-hackers 
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, May 26, 2021 at 11:34:53PM -0400, Tom Lane wrote:
>> So maybe we should just dump the promise that VACUUM FULL will recompress
>> everything?  I'd be in favor of that actually, because it seems 100%
>> outside the charter of either VACUUM FULL or CLUSTER.

> Hmm.  You are right that by default this may not be worth the extra
> cost.  We could make that easily an option, though, for users ready to
> accept this cost.  And that could be handy when it comes to a
> database-wise VACUUM.

AFAIR, there are zero promises about how effective, or when effective,
changes in SET STORAGE will be.  And the number of complaints about
that has also been zero.  So I'm not sure why we need to do more for
SET COMPRESSION.  Especially since I'm unconvinced that recompressing
everything just to recompress everything would *ever* be worthwhile.

			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