On Mon, Mar 8, 2021 at 3:59 PM Justin Pryzby <pry...@telsasoft.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
