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

On Sun, May 23, 2021 at 12:25:10PM -0400, Tom Lane wrote:
> While I've not actually tested this, it seems to me that we could
> just drop these relkind tests altogether. It won't hurt anything
> to set up attcompression in relation descriptors where it'll never
> be consulted.

Wouldn't it be confusing to set up attcompression for relkinds without
storage, like views?

> However, the more I looked at that code the less I liked it.
> I think the way that compression selection is handled for indexes,
> ie consult default_toast_compression on-the-fly, is *far* saner
> than what is currently implemented for tables. So I think we
> should redefine attcompression as "ID of a compression method
> to use, or \0 to select the prevailing default. Ignored if
> attstorage does not permit the use of compression". This would
> result in approximately 99.44% of all columns just having zero
> attcompression, greatly simplifying the tupdesc setup code, and
> also making it much easier to flip an installation over to a
> different preferred compression method.

Would there be any impact when it comes to CTAS or matviews where the
current code assumes that the same compression method as the one from
the original value gets used, making the creation of the new relation
cheaper because there is less de-toasting and re-toasting?
--
Michael