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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-06-02T03:25:08Z
Lists: pgsql-hackers
On Thu, May 27, 2021 at 03:52:06PM -0700, Peter Geoghegan wrote:
> On Thu, May 27, 2021 at 1:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah.  My belief here is that users might bother to change
>> default_toast_compression, or that we might do it for them in a few
>> years, but the gains from doing so are going to be only incremental.
>> That being the case, most DBAs will be content to allow the older
>> compression method to age out of their databases through routine row
>> updates.  The idea that somebody is going to be excited enough about
>> this to run a downtime-inducing VACUUM FULL doesn't really pass the
>> smell test.
> 
> That was my original understanding of your position, FWIW. I agree
> with all of this.

If one wishes to enforce a compression method on a table, the only way
I could see through here, able to bypass the downtime constraint, is 
by using logical replication.  Anybody willing to enforce a new
default compression may accept the cost of setting up instances for
that.
--
Michael

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