Re: [HACKERS] Custom compression methods - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Custom compression methods
Date
Msg-id CA+TgmobGm9umTgno4O4UqSAoGhOPOAA55uiKE8N_wehnHfg4Tw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Custom compression methods  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Custom compression methods  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Custom compression methods  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Fri, Mar 19, 2021 at 4:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Nope ... crake's displeased with your assumption that it's OK to
> clutter dumps with COMPRESSION clauses.  As am I: that is going to
> be utterly fatal for cross-version transportation of dumps.

Yes, and prion's got this concerning diff:

  Column |  Type   | Collation | Nullable | Default | Storage |
Compression | Stats target | Description
 --------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
- f1     | integer |           |          |         | plain   |
     |              |
+ f1     | integer |           |          |         | plain   | pglz
     |              |

Since the column is not a varlena, it shouldn't have a compression
method configured, yet on that machine it does, possibly because that
machine uses -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE.

Regarding your point, that does look like clutter. We don't annotate
the dump with a storage clause unless it's non-default, so probably we
should do the same thing here. I think I gave Dilip bad advice here...

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Custom compression methods
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Custom compression methods