Support mysql ALGORITHM=INPLACE/INSTANT DDL assertions

[morgo]

Feature Request

Is your feature request related to a problem? Please describe:

MySQL supports DDL assertions such as:

ALTER TABLE tbl_name ADD PRIMARY KEY (column), ALGORITHM=INPLACE, LOCK=NONE;

Currently, these are parsed but ignored in TiDB.

Describe the feature you'd like:

• The LOCK=NONE assertion has no meaning in TiDB, since all DDL is lock free.
• The ALGORITHM=COPY also has no meaning in TiDB (since changing primary key is not supported).
• But the ALGORITHM=INPLACE versus ALGORITHM=INSTANT (new in MySQL 8.0) is useful. An operator may choose to have a different workflow for instant vs. in-place changes.

Describe alternatives you've considered:

This feature relates to EXPLAIN for DDL, but there is really a need for both. Due to different row formats, configurations of systems it may be the case that an INSTANT operation on one system is a INPLACE on another.

Teachability, Documentation, Adoption, Migration Strategy:

N/A; mysql compatibility.

[winkyao]

@morgo

mysql> alter table t1 modify column b varchar(100), ALGORITHM=INPLACE;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.

MySQL will return an error if the given ALGORITHM is not supported on some alter operations. In TiDB, the most DDL are using INSTANT, and the add index operation is using INPLACE(not really INPLACE, but cost some time to backfill the index data and will never block the DML). The COPY ALGORITHM is not supported, so do we need to return an error like above for it?

[morgo]

Good question. It is unlikely a user will assert for COPY (they usually assert to make sure an operation doesn't take too long), but a hypothetical case might be to force a table format upgrade.

Since we don't support it (and it's not a common use case), I think it makes sense to error.

[morgo]

Fixed. Closing :-)