Re: [HACKERS] Custom compression methods

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Custom compression methods
Дата
Msg-id CA+TgmobGm9umTgno4O4UqSAoGhOPOAA55uiKE8N_wehnHfg4Tw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Custom compression methods  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Custom compression methods  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Custom compression methods  (Justin Pryzby <pryzby@telsasoft.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Custom compression methods
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Custom compression methods