Re: [HACKERS] Custom compression methods

On Mon, Mar 8, 2021 at 3:59 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > 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 ?

Well, dump and restore will do it, certainly, but I don't think VACUUM
FULL or CLUSTER will. I haven't tested it, though, so maybe I'm wrong.

> > 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".

Oh, yeah. I guess we have to leave that out then.

> 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//'

TBH, that doesn't seem very nice to me. I think it's usually better to
create objects with the right properties initially rather than
creating them wrong and then fixing them afterwards.

> > 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 ?

Oh, man, you want me to look at all the patches and not just the first one? :-)

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