Re: [HACKERS] Custom compression methods

On Mon, Mar 08, 2021 at 03:26:04PM -0500, Robert Haas wrote:
> On Mon, Mar 8, 2021 at 5:02 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > So now only pending point is, how do we handle the upgrade when you
> > are upgrading from --with-lz4 to --without-lz4 binary and a couple of
> > options discussed here are
> > a) Should we allow table creation with lz4 even if it is compiled
> > --without-lz4? In case of xml we always allow table creation even if
> > it is compiled --wthout-libxml
> > b) Instead of allowing this always, only allow during binary upgrade.

> It would be nice to have a way to force
> anything compressed with the old method to be re-compressed with the
> new method, but not having that doesn't preclude allowing the
> parameter to be changed.

Doesn't vacuum full/cluster/dump+restore do that ?

> I think the pg_dump argument should be --no-toast-compression, not
> --no-toast-compressions. I agree with Justin that pg_restore should
> have the option also.

I mentioned that this is hard to do, since the compression is stored inside the
text blob that creates the whole table...Unless toast compression is a
per-relation property rather than per-attribute. I don't think pg_restore
should try to reverse-engineer the text output by pg_dump to elide the
"COMPRESSION lz4".

I think maybe CREATE shouldn't support COMPRESSION at all, and pg_dump/restore
would use ALTER. That makes this very slightly less of an issue, as one can
use pg_restore -f- |grep -v '^ALTER TABLE .* SET COMPRESSION' |psql -d,
rather than sed 's/COMPRESSION lz4//'

> Man, it would be really nice to be able to set the default for new
> tables, rather than having all these places hard-coded to use
> DefaultCompressionMethod. Surely lotsa people are going to want to set
> toast_compression = lz4 in postgresql.conf and forget about it.

I don't understand - isn't that what 0002 does ?

Subject: [PATCH v32 2/4] Add default_toast_compression GUC

--
Justin