Re: [HACKERS] Custom compression methods

On Sun, 5 Nov 2017 17:34:23 -0500
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, Nov 5, 2017 at 2:22 PM, Oleg Bartunov <obartunov(at)gmail(dot)com>
> wrote:
> >> IIRC there were some concerns about what happened with pg_upgrade,
> >> with consuming precious toast bits, and a few other things.
> >
> > yes, pg_upgrade may be a problem.
>
> A basic problem here is that, as proposed, DROP COMPRESSION METHOD may
> break your database irretrievably. If there's no data compressed
> using the compression method you dropped, everything is cool -
> otherwise everything is broken and there's no way to recover. The
> only obvious alternative is to disallow DROP altogether (or make it
> not really DROP).

In the patch I use separate table for compresssion options (because
each attribute can have additional options for compression). So basicly
compressed attribute linked to compression options, not the compression
method and this method can be safely dropped.

So in the next version of the patch I can just unlink the options from
compression methods and dropping compression method will not affect
already compressed tuples. They still could be decompressed.

--
---
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company