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 YLb6FCkU0A+Xo+E6@paquier.xyz
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Peter Geoghegan <pg@bowt.ie>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_get_wal_replay_pause_state() should not return 'paused' while a promotion is ongoing.
Next
From: Michael Paquier
Date:
Subject: Re: be-secure-gssapi.c and auth.c with setenv() not compatible on Windows