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

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.

Comments?

regards, tom lane