[MDEV-15562] Instant DROP COLUMN or changing the order of columns - Jira

Marko Mäkelä created issue - 2018-03-14 12:57

Marko Mäkelä made changes - 2018-03-14 12:57

Field	Original Value	New Value
Link		This issue blocks ~~MDEV-11424~~ [ ~~MDEV-11424~~ ]

Marko Mäkelä made changes - 2018-03-14 13:00

Status

Open [ 1 ]

Confirmed [ 10101 ]

Marko Mäkelä made changes - 2018-03-14 13:00

Link

This issue is blocked by ~~MDEV-11369~~ [ ~~MDEV-11369~~ ]

Marko Mäkelä made changes - 2018-03-14 13:20

Description

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

TO BE DEFINED: The exact change to the ‘default row’ record format.

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

TO BE DEFINED: The exact change to the ‘default row’ record format.

Marko Mäkelä made changes - 2018-05-25 08:31

Description

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

TO BE DEFINED: The exact change to the ‘default row’ record format.

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

TO BE DEFINED: The exact change to the ‘default row’ record format.

Marko Mäkelä made changes - 2018-05-31 08:30

Description

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

TO BE DEFINED: The exact change to the ‘default row’ record format.

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
TO BE DEFINED: The exact change to the ‘default row’ record format.

Marko Mäkelä made changes - 2018-06-26 13:16

Description

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
TO BE DEFINED: The exact change to the ‘default row’ record format.

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
We will change the format of the 'default row record' that was introduced in ~~MDEV-11369~~ as follows:
* In {{info_bits}}, we will set the {{REC_INFO_DELETED_FLAG}} to indicate the presence of column reordering information.
* If {{REC_INFO_DELETED_FLAG}} is set, then the 'number of instantly added columns' will be encoded as starting from 1, so that 0 will mean 'no instantly added columns'.
* If {{REC_INFO_DELETED_FLAG}} is set, then after the dummy {{PRIMARY KEY}} value and the {{DB_TRX_ID,DB_ROLL_PTR}} we will store a BLOB pointer to a page that stores information about dropped and reordered columns.
* After the BLOB pointer, we will include dummy or default values of all non-dropped columns.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'null bits' bitmap will indicate if the dropped column allowed NULL values.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'length' will include the fixed length of the dropped column, or 0 if it was variable-length.

h3. The 'default row' BLOB format
The payload of the BLOB will contain the following:
* 32 bits: Number of fields in the clustered index, including any instantly added or dropped non-virtual columns (32 bits)
* An array of 16 bits * n_fields: The location of each field in the physical clustered index record.
* If the entry is 0, it means that the column was dropped.
* If the entry is 1, the column was dropped, the table is in COMPACT or DYNAMIC format, and the maximum length of the variable-length column was more than 255 bytes (encoding the length in the user record takes 1 or 2 bytes). (This value is not possible for REDUNDANT format.)
* Else, the entry will be 2‥n_fields+1, mapping the {{dict_index_t::fields[]}} of the clustered index of the latest table definition to fields in the clustered index records.

h2. Limitations
The maximum number of fields in a clustered index is a little less than 1023 fields. This limit is imposed by the redo log format as well as some main-memory data structures. This number includes any instantly dropped columns in the history of the table.

The minimum record length will include instantly dropped columns that were {{NOT NULL}} and fixed-length. It must be possible to insert at least 2 minimum-length records into a clustered index leaf page.

If these limits would be violated by {{ADD COLUMN}} after instant {{DROP COLUMN}}, then the operation cannot be performed as an instant operation, but it can be executed as a table-rebuild ({{ALGORITHM=INSTANT}} or {{ALGORITHM=COPY}}, but not {{ALGORITHM=NOCOPY}} or {{ALGORITHM=INSTANT}}).

Marko Mäkelä made changes - 2018-06-26 13:34

Description

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
We will change the format of the 'default row record' that was introduced in ~~MDEV-11369~~ as follows:
* In {{info_bits}}, we will set the {{REC_INFO_DELETED_FLAG}} to indicate the presence of column reordering information.
* If {{REC_INFO_DELETED_FLAG}} is set, then the 'number of instantly added columns' will be encoded as starting from 1, so that 0 will mean 'no instantly added columns'.
* If {{REC_INFO_DELETED_FLAG}} is set, then after the dummy {{PRIMARY KEY}} value and the {{DB_TRX_ID,DB_ROLL_PTR}} we will store a BLOB pointer to a page that stores information about dropped and reordered columns.
* After the BLOB pointer, we will include dummy or default values of all non-dropped columns.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'null bits' bitmap will indicate if the dropped column allowed NULL values.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'length' will include the fixed length of the dropped column, or 0 if it was variable-length.

h3. The 'default row' BLOB format
The payload of the BLOB will contain the following:
* 32 bits: Number of fields in the clustered index, including any instantly added or dropped non-virtual columns (32 bits)
* An array of 16 bits * n_fields: The location of each field in the physical clustered index record.
* If the entry is 0, it means that the column was dropped.
* If the entry is 1, the column was dropped, the table is in COMPACT or DYNAMIC format, and the maximum length of the variable-length column was more than 255 bytes (encoding the length in the user record takes 1 or 2 bytes). (This value is not possible for REDUNDANT format.)
* Else, the entry will be 2‥n_fields+1, mapping the {{dict_index_t::fields[]}} of the clustered index of the latest table definition to fields in the clustered index records.

h2. Limitations
The maximum number of fields in a clustered index is a little less than 1023 fields. This limit is imposed by the redo log format as well as some main-memory data structures. This number includes any instantly dropped columns in the history of the table.

The minimum record length will include instantly dropped columns that were {{NOT NULL}} and fixed-length. It must be possible to insert at least 2 minimum-length records into a clustered index leaf page.

If these limits would be violated by {{ADD COLUMN}} after instant {{DROP COLUMN}}, then the operation cannot be performed as an instant operation, but it can be executed as a table-rebuild ({{ALGORITHM=INSTANT}} or {{ALGORITHM=COPY}}, but not {{ALGORITHM=NOCOPY}} or {{ALGORITHM=INSTANT}}).

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
We will change the format of the 'default row record' that was introduced in ~~MDEV-11369~~ as follows:
* In {{info_bits}}, we will set the {{REC_INFO_DELETED_FLAG}} to indicate the presence of column reordering information.
* If {{REC_INFO_DELETED_FLAG}} is set, then the 'number of instantly added columns' will be encoded as starting from 1, so that 0 will mean 'no instantly added columns'.
* If {{REC_INFO_DELETED_FLAG}} is set, then after the dummy {{PRIMARY KEY}} value and the {{DB_TRX_ID,DB_ROLL_PTR}} we will store a BLOB pointer to a page that stores information about dropped and reordered columns.
* After the BLOB pointer, we will include dummy or default values of all non-dropped columns.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'null bits' bitmap will indicate if the dropped column allowed NULL values.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'length' array will include 1 or 2 lengths for each dropped column, using variable-length encoding: the fixed length (0 if variable-length), and the maximum length if variable-length. Both lengths will use the variable-length encoding (1 byte for 0..127, else 2 bytes).
* In ROW_FORMAT=REDUNDANT, for any subsequently updated or inserted records, instantly dropped columns will be stored as 0 bytes. (In this format, each column is basically stored as variable-length.)

h3. The 'default row' BLOB format
The payload of the BLOB will contain the following:
* 32 bits: Number of fields in the clustered index, including any instantly added or dropped non-virtual columns (32 bits)
* An array of 16 bits * n_fields: The location of each field in the physical clustered index record.
* If the entry is 0, it means that the column was dropped.
* Else, the entry will be 1‥n_fields, mapping the {{dict_index_t::fields[]}} of the clustered index of the latest table definition to fields in the clustered index records.

h2. Limitations
The maximum number of fields in a clustered index is a little less than 1023 fields. This limit is imposed by the redo log format as well as some main-memory data structures. This number includes any instantly dropped columns in the history of the table.

The minimum record length will include instantly dropped columns that were {{NOT NULL}} and fixed-length. It must be possible to insert at least 2 minimum-length records into a clustered index leaf page.

If these limits would be violated by {{ADD COLUMN}} after instant {{DROP COLUMN}}, then the operation cannot be performed as an instant operation, but it can be executed as a table-rebuild ({{ALGORITHM=INSTANT}} or {{ALGORITHM=COPY}}, but not {{ALGORITHM=NOCOPY}} or {{ALGORITHM=INSTANT}}).

Julien Fritsch made changes - 2018-07-05 14:24

Epic Link

PT-80 [ 68561 ]

Ralf Gebhardt made changes - 2018-08-21 16:40

Priority

Major [ 3 ]

Critical [ 2 ]

Ralf Gebhardt made changes - 2018-08-21 16:41

NRE Approved

Yes [ 10304 ]

Ralf Gebhardt made changes - 2018-08-23 13:07

Rank

Ranked higher

Ralf Gebhardt made changes - 2018-09-13 10:52

Target end

12/Feb/19 [ 2019-02-12 ]

Marko Mäkelä made changes - 2018-09-17 14:29

Assignee

Thirunarayanan Balathandayuthapani [ thiru ]

Marko Mäkelä [ marko ]

Marko Mäkelä made changes - 2018-09-18 20:19

Status

Confirmed [ 10101 ]

In Progress [ 3 ]

Marko Mäkelä made changes - 2018-09-21 16:31

Description

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden ‘default row’ record that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
We will change the format of the 'default row record' that was introduced in ~~MDEV-11369~~ as follows:
* In {{info_bits}}, we will set the {{REC_INFO_DELETED_FLAG}} to indicate the presence of column reordering information.
* If {{REC_INFO_DELETED_FLAG}} is set, then the 'number of instantly added columns' will be encoded as starting from 1, so that 0 will mean 'no instantly added columns'.
* If {{REC_INFO_DELETED_FLAG}} is set, then after the dummy {{PRIMARY KEY}} value and the {{DB_TRX_ID,DB_ROLL_PTR}} we will store a BLOB pointer to a page that stores information about dropped and reordered columns.
* After the BLOB pointer, we will include dummy or default values of all non-dropped columns.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'null bits' bitmap will indicate if the dropped column allowed NULL values.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'length' array will include 1 or 2 lengths for each dropped column, using variable-length encoding: the fixed length (0 if variable-length), and the maximum length if variable-length. Both lengths will use the variable-length encoding (1 byte for 0..127, else 2 bytes).
* In ROW_FORMAT=REDUNDANT, for any subsequently updated or inserted records, instantly dropped columns will be stored as 0 bytes. (In this format, each column is basically stored as variable-length.)

h3. The 'default row' BLOB format
The payload of the BLOB will contain the following:
* 32 bits: Number of fields in the clustered index, including any instantly added or dropped non-virtual columns (32 bits)
* An array of 16 bits * n_fields: The location of each field in the physical clustered index record.
* If the entry is 0, it means that the column was dropped.
* Else, the entry will be 1‥n_fields, mapping the {{dict_index_t::fields[]}} of the clustered index of the latest table definition to fields in the clustered index records.

h2. Limitations
The maximum number of fields in a clustered index is a little less than 1023 fields. This limit is imposed by the redo log format as well as some main-memory data structures. This number includes any instantly dropped columns in the history of the table.

The minimum record length will include instantly dropped columns that were {{NOT NULL}} and fixed-length. It must be possible to insert at least 2 minimum-length records into a clustered index leaf page.

If these limits would be violated by {{ADD COLUMN}} after instant {{DROP COLUMN}}, then the operation cannot be performed as an instant operation, but it can be executed as a table-rebuild ({{ALGORITHM=INSTANT}} or {{ALGORITHM=COPY}}, but not {{ALGORITHM=NOCOPY}} or {{ALGORITHM=INSTANT}}).

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden metadata record (originally called ‘default row’) that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
We will change the format of the metadata record that was introduced in ~~MDEV-11369~~ as follows:
* In {{info_bits}}, we will set the {{REC_INFO_DELETED_FLAG}} to indicate the presence of column reordering information.
* If {{REC_INFO_DELETED_FLAG}} is set, then the 'number of instantly added columns' will be encoded as starting from 1, so that 0 will mean 'no instantly added columns'.
* If {{REC_INFO_DELETED_FLAG}} is set, then after the dummy {{PRIMARY KEY}} value and the {{DB_TRX_ID,DB_ROLL_PTR}} we will store a BLOB pointer to a page that stores information about dropped and reordered columns.
* After the BLOB pointer, we will include dummy or default values of all non-dropped columns.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'null bits' bitmap will indicate if the dropped column allowed NULL values.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'length' array will include 1 or 2 lengths for each dropped column, using variable-length encoding: the fixed length (0 if variable-length), and the maximum length if variable-length. Both lengths will use the variable-length encoding (1 byte for 0..127, else 2 bytes).
* In ROW_FORMAT=REDUNDANT, for any subsequently updated or inserted records, instantly dropped columns will be stored as 0 bytes. (In this format, each column is basically stored as variable-length.)

h3. The metadata BLOB format
The payload of the BLOB will contain the following:
* 32 bits: Number of fields in the clustered index, including any instantly added or dropped non-virtual columns
* An array of 16 bits * n_fields: The location of each field in the physical clustered index record.
* If the entry is 0, it means that the column was dropped.
* Else, the entry will be 1‥n_fields, mapping the {{dict_index_t::fields[]}} of the clustered index of the latest table definition to fields in the clustered index records.
* This BLOB will always be stored off-page. Only the 20-byte BLOB pointer will be added to the metadata record, in any supported {{ROW_FORMAT}}.
* The unused trailer of the BLOB page must be zero-initialized. If there are nonzero bytes in the unknown area, we will refuse to open the table. This area is reserved for future extension.

h2. Limitations
The maximum number of fields in a clustered index is a little less than 1023 fields. This limit is imposed by the redo log format as well as some main-memory data structures. This number includes any instantly dropped columns in the history of the table.

The minimum record length will include instantly dropped columns that were {{NOT NULL}} and fixed-length. It must be possible to insert at least 2 minimum-length records into a clustered index leaf page.

If these limits would be violated by {{ADD COLUMN}} after instant {{DROP COLUMN}}, then the operation cannot be performed as an instant operation, but it can be executed as a table-rebuild ({{ALGORITHM=INSTANT}} or {{ALGORITHM=COPY}}, but not {{ALGORITHM=NOCOPY}} or {{ALGORITHM=INSTANT}}).

Marko Mäkelä made changes - 2018-10-03 14:01

Description

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden metadata record (originally called ‘default row’) that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
We will change the format of the metadata record that was introduced in ~~MDEV-11369~~ as follows:
* In {{info_bits}}, we will set the {{REC_INFO_DELETED_FLAG}} to indicate the presence of column reordering information.
* If {{REC_INFO_DELETED_FLAG}} is set, then the 'number of instantly added columns' will be encoded as starting from 1, so that 0 will mean 'no instantly added columns'.
* If {{REC_INFO_DELETED_FLAG}} is set, then after the dummy {{PRIMARY KEY}} value and the {{DB_TRX_ID,DB_ROLL_PTR}} we will store a BLOB pointer to a page that stores information about dropped and reordered columns.
* After the BLOB pointer, we will include dummy or default values of all non-dropped columns.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'null bits' bitmap will indicate if the dropped column allowed NULL values.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'length' array will include 1 or 2 lengths for each dropped column, using variable-length encoding: the fixed length (0 if variable-length), and the maximum length if variable-length. Both lengths will use the variable-length encoding (1 byte for 0..127, else 2 bytes).
* In ROW_FORMAT=REDUNDANT, for any subsequently updated or inserted records, instantly dropped columns will be stored as 0 bytes. (In this format, each column is basically stored as variable-length.)

h3. The metadata BLOB format
The payload of the BLOB will contain the following:
* 32 bits: Number of fields in the clustered index, including any instantly added or dropped non-virtual columns
* An array of 16 bits * n_fields: The location of each field in the physical clustered index record.
* If the entry is 0, it means that the column was dropped.
* Else, the entry will be 1‥n_fields, mapping the {{dict_index_t::fields[]}} of the clustered index of the latest table definition to fields in the clustered index records.
* This BLOB will always be stored off-page. Only the 20-byte BLOB pointer will be added to the metadata record, in any supported {{ROW_FORMAT}}.
* The unused trailer of the BLOB page must be zero-initialized. If there are nonzero bytes in the unknown area, we will refuse to open the table. This area is reserved for future extension.

h2. Limitations
The maximum number of fields in a clustered index is a little less than 1023 fields. This limit is imposed by the redo log format as well as some main-memory data structures. This number includes any instantly dropped columns in the history of the table.

The minimum record length will include instantly dropped columns that were {{NOT NULL}} and fixed-length. It must be possible to insert at least 2 minimum-length records into a clustered index leaf page.

If these limits would be violated by {{ADD COLUMN}} after instant {{DROP COLUMN}}, then the operation cannot be performed as an instant operation, but it can be executed as a table-rebuild ({{ALGORITHM=INSTANT}} or {{ALGORITHM=COPY}}, but not {{ALGORITHM=NOCOPY}} or {{ALGORITHM=INSTANT}}).

~~MDEV-11369~~ implemented instant {{ALTER TABLE…ADD COLUMN}} by introducing a hidden metadata record (originally called ‘default row’) that stores metadata of the original table structure. Based on this record, we know the original structure of the clustered index (where the data is stored together with the {{PRIMARY KEY}}). The latest structure is persisted in the data dictionary.

We can extend the format of the hidden record to store a mapping between clustered index fields and table columns. Any {{ADD COLUMN}} would be instantly added as last field in the clustered index record, but the field-to-column map would allow it to be positioned anywhere in the table. Any {{DROP COLUMN}} will simply detach the clustered index field from the table columns.

Note: {{DROP COLUMN}} of an indexed column would imply {{DROP INDEX}} (and in the case of a non-{{UNIQUE}} multi-column index, possibly {{ADD INDEX}}). These will no be allowed with {{ALGORITHM=INSTANT}}, but unlike before this work, they can be allowed with {{ALGORITHM=NOCOPY}}. Also, ~~MDEV-16223~~ could defer the {{ADD INDEX}}, allowing the {{DROP COLUMN}} operation to complete faster.

Note: While this work would enable the ordering of columns in the {{SELECT * FROM t}} to be changed instantaneously, changing the ordering of {{PRIMARY KEY}} columns (such as changing {{PRIMARY KEY(a,b)}} to {{PRIMARY KEY(b,a)}}) would continue to require a full table rebuild. The syntax for this is:
{code:sql}
ALTER TABLE t DROP PRIMARY KEY, ADD PRIMARY KEY(b,a);
{code}

h2. Data format changes
Instantly added columns are added last in the user records, in the format that was introduced by ~~MDEV-11369~~.

For instantly dropped columns, {{INSERT}} and {{UPDATE}} will continue to write dummy values as follows:
* In {{ROW_FORMAT=REDUNDANT}}, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for columns that allow {{NULL}}, write {{NULL}}.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for variable-length {{NOT NULL}} columns, write 0-byte fields.
* In {{ROW_FORMAT=COMPACT}} or {{ROW_FORMAT=DYNAMIC}}, for fixed-length {{NOT NULL}} columns, zero-fill the fixed length of bytes.

h2. Metadata format changes
We will change the format of the metadata record that was introduced in ~~MDEV-11369~~ as follows:
* In {{info_bits}}, we will set the {{REC_INFO_DELETED_FLAG}} to indicate the presence of column reordering information (a BLOB field).
* If {{REC_INFO_DELETED_FLAG}} is set, then the 'number of instantly added columns' will be encoded as starting from 1, so that 0 will mean that only the new BLOB field is present.
* If {{REC_INFO_DELETED_FLAG}} is set, then after the dummy {{PRIMARY KEY}} value and the {{DB_TRX_ID,DB_ROLL_PTR}} we will store a BLOB pointer to a page that stores information about dropped and reordered columns.
* After the BLOB pointer, we will include dummy or default values of all non-dropped columns.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'null bits' bitmap will indicate if the dropped column allowed NULL values.
* In COMPACT or DYNAMIC ROW_FORMAT, for dropped columns, the 'length' array will include 1 or 2 lengths for each dropped column, using variable-length encoding: the fixed length (0 if variable-length), and the maximum length if variable-length. Both lengths will use the variable-length encoding (1 byte for 0..127, else 2 bytes).
* In ROW_FORMAT=REDUNDANT, for any subsequently updated or inserted records, instantly dropped columns will be stored as 0 bytes. (In this format, each column is basically stored as variable-length.)

h3. The metadata BLOB format
The payload of the BLOB will contain the following:
* 32 bits: Number of fields in the clustered index, including any instantly added or dropped non-virtual columns
* An array of 16 bits * n_fields: The location of each field in the physical clustered index record.
* If the most significant bit is set, it means that the column was dropped, and the remaining bits contain the {{NOT NULL}} flag and the {{fixed_len}} (0 if variable-length).
* Else, the entry will be 0‥n_fields-1, mapping the {{dict_index_t::fields[]}} of the clustered index of the latest table definition to fields in the clustered index records.
* This BLOB will always be stored off-page. Only the 20-byte BLOB pointer will be added to the metadata record, in any supported {{ROW_FORMAT}}.
* The unused trailer of the BLOB page must be zero-initialized. If there are nonzero bytes in the unknown area, we will refuse to open the table. This area is reserved for future extension.

h2. Limitations
The maximum number of fields in a clustered index is a little less than 1023 fields. This limit is imposed by the redo log format as well as some main-memory data structures. This number includes any instantly dropped columns in the history of the table.

The minimum record length will include instantly dropped columns that were {{NOT NULL}} and fixed-length. It must be possible to insert at least 2 minimum-length records into a clustered index leaf page.

If these limits would be violated by {{ADD COLUMN}} after instant {{DROP COLUMN}}, then the operation cannot be performed as an instant operation, but it can be executed as a table-rebuild ({{ALGORITHM=INSTANT}} or {{ALGORITHM=COPY}}, but not {{ALGORITHM=NOCOPY}} or {{ALGORITHM=INSTANT}}).

Marko Mäkelä made changes - 2018-10-15 15:05

Link

This issue relates to MDEV-17459 [ MDEV-17459 ]

Marko Mäkelä made changes - 2018-10-16 08:58

Link

This issue relates to MDEV-17468 [ MDEV-17468 ]

Marko Mäkelä made changes - 2018-10-18 20:05

Link

This issue causes ~~MDEV-17494~~ [ ~~MDEV-17494~~ ]

Marko Mäkelä made changes - 2018-10-19 16:04

issue.field.resolutiondate

2018-10-19 16:04:32.0

2018-10-19 16:04:32.466

Marko Mäkelä made changes - 2018-10-19 16:04

Fix Version/s		10.4.0 [ 23115 ]
Fix Version/s	10.4 [ 22408 ]
Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Closed [ 6 ]

Marko Mäkelä made changes - 2018-10-22 14:35

Link

This issue blocks MDEV-17520 [ MDEV-17520 ]

Marko Mäkelä made changes - 2018-11-16 11:24

Link

This issue causes ~~MDEV-17735~~ [ ~~MDEV-17735~~ ]

Marko Mäkelä made changes - 2018-11-22 07:26

Link

This issue causes ~~MDEV-17793~~ [ ~~MDEV-17793~~ ]

Marko Mäkelä made changes - 2018-11-23 10:32

Link

This issue causes ~~MDEV-17813~~ [ ~~MDEV-17813~~ ]

Marko Mäkelä made changes - 2018-11-23 16:50

Link

This issue causes ~~MDEV-17721~~ [ ~~MDEV-17721~~ ]

Marko Mäkelä made changes - 2018-11-26 13:04

Link

This issue relates to ~~MDEV-17831~~ [ ~~MDEV-17831~~ ]

Marko Mäkelä made changes - 2018-12-10 14:44

Link

This issue causes ~~MDEV-17899~~ [ ~~MDEV-17899~~ ]

Marko Mäkelä made changes - 2018-12-11 18:58

Link

This issue causes ~~MDEV-17901~~ [ ~~MDEV-17901~~ ]

Marko Mäkelä made changes - 2018-12-14 03:45

Link

This issue causes ~~MDEV-18007~~ [ ~~MDEV-18007~~ ]

Marko Mäkelä made changes - 2018-12-28 12:31

Link

This issue causes ~~MDEV-18098~~ [ ~~MDEV-18098~~ ]

Marko Mäkelä made changes - 2019-01-09 17:44

Link

This issue causes ~~MDEV-18190~~ [ ~~MDEV-18190~~ ]

Marko Mäkelä made changes - 2019-02-11 16:17

Link

This issue causes ~~MDEV-18543~~ [ ~~MDEV-18543~~ ]

Marko Mäkelä made changes - 2019-03-01 09:43

Link

This issue relates to ~~MDEV-18775~~ [ ~~MDEV-18775~~ ]

Marko Mäkelä made changes - 2019-03-22 14:39

Link

This issue is duplicated by ~~MDEV-18622~~ [ ~~MDEV-18622~~ ]

Marko Mäkelä made changes - 2019-05-16 11:07

Link

This issue causes ~~MDEV-19485~~ [ ~~MDEV-19485~~ ]

Marko Mäkelä made changes - 2019-07-19 13:43

Link

This issue causes ~~MDEV-20048~~ [ ~~MDEV-20048~~ ]

Marko Mäkelä made changes - 2019-08-21 09:37

Link

This issue causes ~~MDEV-20117~~ [ ~~MDEV-20117~~ ]

Marko Mäkelä made changes - 2019-08-26 08:06

Link

This issue relates to MDEV-20419 [ MDEV-20419 ]

Marko Mäkelä made changes - 2019-08-29 07:50

Link

This issue causes ~~MDEV-20066~~ [ ~~MDEV-20066~~ ]

Marko Mäkelä made changes - 2019-08-30 10:42

Link

This issue causes ~~MDEV-20066~~ [ ~~MDEV-20066~~ ]

Marko Mäkelä made changes - 2019-11-19 19:05

Link

This issue causes ~~MDEV-21088~~ [ ~~MDEV-21088~~ ]

Marko Mäkelä made changes - 2020-01-15 16:06

Link

This issue causes ~~MDEV-21485~~ [ ~~MDEV-21485~~ ]

Marko Mäkelä made changes - 2020-01-31 08:05

Link

This issue causes ~~MDEV-17844~~ [ ~~MDEV-17844~~ ]

Marko Mäkelä made changes - 2020-02-05 07:58

Link

This issue causes ~~MDEV-21645~~ [ ~~MDEV-21645~~ ]

Marko Mäkelä made changes - 2020-02-05 12:36

Link

This issue causes ~~MDEV-21658~~ [ ~~MDEV-21658~~ ]

Marko Mäkelä made changes - 2020-02-25 11:50

Link

This issue relates to ~~MDEV-21693~~ [ ~~MDEV-21693~~ ]

Marko Mäkelä made changes - 2020-06-17 16:13

Link

This issue causes ~~MDEV-22902~~ [ ~~MDEV-22902~~ ]

Marko Mäkelä made changes - 2020-07-24 16:27

Link

This issue causes ~~MDEV-22651~~ [ ~~MDEV-22651~~ ]

Marko Mäkelä made changes - 2020-10-19 10:22

Link

This issue causes ~~MDEV-23672~~ [ ~~MDEV-23672~~ ]

Marko Mäkelä made changes - 2021-01-02 13:46

Link

This issue causes ~~MDEV-24512~~ [ ~~MDEV-24512~~ ]

Marko Mäkelä made changes - 2021-03-26 12:58

Link

This issue causes MDEV-19202 [ MDEV-19202 ]

Sergei Golubchik made changes - 2021-12-06 21:23

Workflow

MariaDB v3 [ 86021 ]

MariaDB v4 [ 133493 ]

Marko Mäkelä made changes - 2022-01-12 07:33

Link

This issue causes ~~MDEV-20198~~ [ ~~MDEV-20198~~ ]

Marko Mäkelä made changes - 2022-06-07 09:02

Link

This issue relates to ~~MDEV-28760~~ [ ~~MDEV-28760~~ ]

Marko Mäkelä made changes - 2022-06-21 08:00

Link

This issue causes ~~MDEV-28919~~ [ ~~MDEV-28919~~ ]

Marko Mäkelä made changes - 2022-07-26 13:33

Link

This issue causes ~~MDEV-26420~~ [ ~~MDEV-26420~~ ]

Marko Mäkelä made changes - 2022-08-01 13:34

Link

This issue causes MDEV-26141 [ MDEV-26141 ]

Marko Mäkelä made changes - 2022-09-01 09:48

Link

This issue relates to ~~MDEV-29438~~ [ ~~MDEV-29438~~ ]

Marko Mäkelä made changes - 2022-09-01 11:44

Link

This issue relates to ~~MDEV-29440~~ [ ~~MDEV-29440~~ ]

Marko Mäkelä made changes - 2022-11-15 12:21

Link

This issue relates to ~~MDEV-28462~~ [ ~~MDEV-28462~~ ]

Marko Mäkelä made changes - 2023-11-03 06:57

Link

This issue relates to MDEV-32668 [ MDEV-32668 ]

Marko Mäkelä made changes - 2024-10-11 04:57

Link

This issue causes ~~MDEV-35122~~ [ ~~MDEV-35122~~ ]

MariaDB Server

Instant DROP COLUMN or changing the order of columns

Details

Description

Data format changes

Metadata format changes

The metadata BLOB format

Limitations

Attachments

Issue Links

Activity

People

Dates

Git Integration