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 YK7kKhV1fyWdAynz@paquier.xyz
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
List pgsql-hackers
On Wed, May 26, 2021 at 07:44:03PM -0400, Alvaro Herrera wrote:
> On 2021-May-26, Tom Lane wrote:
>> Personally I won't touch 002_pg_dump.pl with a 10-foot pole, but if
>> somebody else wants to, have at it.
>
> Nod.

Yeah, having an extra test for partitioned tables would be a good
idea.

>> Hm, there's this in compression.sql:
>>
>> -- test LIKE INCLUDING COMPRESSION
>> CREATE TABLE cmdata2 (LIKE cmdata1 INCLUDING COMPRESSION);
>> \d+ cmdata2
>>
>> Or did you mean the case with a partitioned table specifically?
>
> Ah, I guess that's sufficient.  (The INCLUDING clause cannot be used to
> create a partition, actually.)

+column_compression:
+           COMPRESSION ColId                       { $$ = $2; }
+           | COMPRESSION DEFAULT                   { $$ =
pstrdup("default"); }
Could it be possible to have some tests for COMPRESSION DEFAULT?  It
seems to me that this should be documented as a supported keyword for
CREATE/ALTER TABLE.

 --changing column storage should not impact the compression method
 --but the data should not be compressed
 ALTER TABLE cmdata2 ALTER COLUMN f1 TYPE varchar;
+ALTER TABLE cmdata2 ALTER COLUMN f1 SET COMPRESSION pglz;
This comment needs a refresh?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: storing an explicit nonce
Next
From: Tom Lane
Date:
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?