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

On Wed, May 26, 2021 at 11:13:46AM -0400, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > Ah, the parallel with reltablespace and default_tablespace at database
> > level is a very good point. It is true that currently the code would
> > assign attcompression to a non-zero value once the relation is defined
> > depending on default_toast_compression set for the database, but
> > setting it to 0 in this case would be really helpful to change the
> > compression methods of all the relations if doing something as crazy
> > as a VACUUM FULL for this database. Count me as convinced.
>
> Here's a draft patch series to address this.
>
> 0001 removes the relkind checks I was questioning originally.
> As expected, this results in zero changes in check-world results.
>
> 0002 is the main change in the semantics of attcompression.
> This does change the results of compression.sql, but in what
> seem to me to be expected ways: a column's compression option
> is now shown in \d+ output only if you explicitly set it.
>
> 0003 further removes pg_dump's special handling of
> default_toast_compression. I don't think we need that anymore.
> AFAICS its only effect would be to override the receiving server's
> default_toast_compression setting for dumped/re-loaded data, which
> does not seem like a behavior that anyone would want.
>
> Loose ends:
>
> * I've not reviewed the docs fully; there are likely some more
> things that need updated.
>
> * As things stand here, once you've applied ALTER ... SET COMPRESSION
> to select a specific method, there is no way to undo that and go
> back to the use-the-default setting. All you can do is change to
> explicitly select the other method. Should we invent "ALTER ...
> SET COMPRESSION default" or the like to cover that? (Since
> DEFAULT is a reserved word, that exact syntax might be a bit of
> a pain to implement, but maybe we could think of another word.)
>
> * I find GetDefaultToastCompression() annoying. I do not think
> it is project style to invent trivial wrapper functions around
> GUC variable references: it buys nothing while requiring readers
> to remember one more name than they would otherwise. Since there
> are only two uses remaining, maybe this isn't very important either
> way, but I'm still inclined to flush it.

+1

It existed when default_toast_compression was a text string. Since e5595de03,
it's an enum/int/char, and serves no purpose.

--
Justin