On Mon, Dec 11, 2017 at 12:41 PM, Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > Thus, in your example if user would like to further change awesome > compression for evenbetter compression, she should write. > > SET COMPRESSION evenbetter PRESERVE pglz, awesome; -- full list of previous > compression methods
Right. > I wonder what should we do if user specifies only part of previous > compression methods? For instance, pglz is specified but awesome is > missing. > > SET COMPRESSION evenbetter PRESERVE pglz; -- awesome is missing > > I think we should trigger an error in this case. Because query is specified > in form that is assuming to work without table rewrite, but we're unable to > do this without table rewrite. I think that should just rewrite the table in that case. PRESERVE should specify the things that are allowed to be preserved -- its mere presence should not be read to preclude a rewrite. And it's completely reasonable for someone to want to do this, if they are thinking about de-installing awesome. > I also think that we need some way to change compression method for multiple > columns in a single table rewrite. Because it would be way more efficient > than rewriting table for each of columns. So as an alternative of > > ALTER TABLE tbl ALTER COLUMN c1 SET COMPRESSION awesome; -- first table > rewrite > ALTER TABLE tbl ALTER COLUMN c2 SET COMPRESSION awesome; -- second table > rewrite > > we could also provide > > ALTER TABLE tbl ALTER COLUMN c1 SET COMPRESSION awesome PRESERVE pglz; -- no > rewrite > ALTER TABLE tbl ALTER COLUMN c2 SET COMPRESSION awesome PRESERVE pglz; -- no > rewrite > VACUUM FULL tbl RESET COMPRESSION PRESERVE c1, c2; -- rewrite with > recompression of c1 and c2 and removing depedencies > > ? Hmm. ALTER TABLE allows multi comma-separated subcommands, so I don't think we need to drag VACUUM into this. The user can just say: ALTER TABLE tbl ALTER COLUMN c1 SET COMPRESSION awesome, ALTER COLUMN c2 SET COMPRESSION awesome; If this is properly integrated into tablecmds.c, that should cause a single rewrite affecting both columns. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
