Re: Move pg_attribute.attcompression to earlier in struct for reduced size? - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date
Msg-id 20210527221019.GG2082@telsasoft.com
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Tue, May 25, 2021 at 08:33:47PM -0500, Justin Pryzby wrote:
> On Sun, May 23, 2021 at 12:25:10PM -0400, Tom Lane wrote:
> > 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".
> 
> +1
> 
> It reminds me of reltablespace, which is stored as 0 to mean the database's
> default tablespace.

I was surprised to realize that I made this same suggestion last month...
https://www.postgresql.org/message-id/20210320074420.GR11765@telsasoft.com
|..unless we changed attcompression='\0' to mean (for varlena) "the default
|compression".  Rather than "resolving" to the default compression at the time
|the table is created, columns without an explicit compression set would "defer"
|to the GUC (of course, that only affects newly-inserted data).

The original reason for that suggestion Michael handled differently in
63db0ac3f9e6bae313da67f640c95c0045b7f0ee

-- 
Justin



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: storing an explicit nonce
Next
From: Andres Freund
Date:
Subject: Re: storing an explicit nonce