ALTER TABLE SET ACCESS METHOD: AO->AOCO support

[huansong]

READY to review

Description

Currently adding support for the following cases:

CREATE TABLE foo(a int) WITH (appendonly=true);
ALTER TABLE foo SET ACCESS METHOD ao_column;
-- or:
ALTER TABLE foo SET WITH (appendonly=true, orientation=column);

Similar to other variations of ATSETAM commands, user can also specify reloptions in a WITH clause, such as:

ALTER TABLE foo SET ACCESS METHOD ao_column WITH (blocksize=65536);

If no reloptions are given, the new AOCO table will use the existing table-level options for its column encoding options. If any reloption is given in the WITH clause, it will be recorded in the catalog and then used for the column encoding option too.

Note that there was once a thought to support specifying column-level encoding in the ATSETAM command, but was abandoned because there exists better alternatives. Discussions see https://groups.google.com/a/greenplum.org/g/gpdb-dev/c/NaNH6TssgA8

Things that's not covered in this PR

SET column-level options w/o changing AM

We have another story that we'll try to support setting column-specific encoding in the following syntax:

ALTER TABLE foo ALTER COLUMN a SET (blocksize=65536);

Note that, after that is supported, we may also do ATSETAM to AOCO table and set column-level options in one statement, e.g.:

ALTER TABLE foo SET ACCESS METHOD ao_column, ALTER COLUMN b SET (blocksize=65536);

This doesn't even need a syntax change. But the thing is that we won't be able to set the DEFAULT column encoding options. To do that we would still need to define new syntax in one way or another. For me, doing so in the WITH clause for both ALTER TABLE SET ACCESS METHOD WITH() and ALTER TABLE SET WITH() commands seems to be a better way.

ADD COLUMN with ENCODING

There's also a thought to support ADD COLUMN with changing AM to AOCO, e.g.:

ALTER TABLE foo SET ACCESS METHOD ao_column, ADD b int ENCODING (blocksize=32768);

But the issue is that at the time when we add the column & encoding, the table is still non-AOCO and we need to work around that. That requires some nontrivial change to the ALTER TABLE framework given how things are. Since this is mostly just a syntactic sugar, we probably don't need to deal with that now.

Here are some reminders before you submit the pull request

• [ ] Add tests for the change
• [ ] Document changes
• [ ] Communicate in the mailing list if needed
• [ ] Pass make installcheck
• [ ] Review a PR in return to support the community