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

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> 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?

No more so than setting up attstorage, surely.

>> ... 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?

I'd still envision copying the source attcompression setting in such
cases. I guess the question is (a) does that code path actually
recompress values that have the "wrong" compression, and (b) if it
does, is that wrong? If you think (a) is correct behavior, then
I don't see why refreshing after changing default_toast_compression
shouldn't cause that to happen.

regards, tom lane