Reorganize multiple history partitions

Summary

Extend ALTER TABLE ... REORGANIZE PARTITION for tables partitioned by SYSTEM_TIME so that multiple HISTORY partitions can be merged and, where supported, one history partition can be split into multiple history partitions.

The feature must support:

• Renaming a history partition without changing the partition count.
• Merging multiple history partitions into one history partition.
• Splitting one history partition into multiple history partitions.
• Redistributing historical rows between resulting partitions.
• Preserving exactly one CURRENT partition.
• Rebuilding the internal working-history-partition state after reorganization.
• Atomic and crash-safe completion of the operation.

The permitted operations depend on the history-rotation method:

Rationale

Ordinary REORGANIZE PARTITION supports changing the number and layout of RANGE and LIST partitions without losing data. It can split one partition into several partitions, merge several partitions into one, or rename a partition.

A table partitioned by SYSTEM_TIME can contain multiple history partitions, but the current implementation permits only reorganizations that preserve the number of partitions.

Renaming already works:

CREATE OR REPLACE TABLE t1 (x INT)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME;

ALTER TABLE t1

  REORGANIZE PARTITION p0

  INTO (

    PARTITION custom_name HISTORY

  );

Splitting a history partition does not work:

CREATE OR REPLACE TABLE t1 (x INT)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME;

ALTER TABLE t1

  REORGANIZE PARTITION p0

  INTO (

    PARTITION p0 HISTORY,

    PARTITION p1 HISTORY

  );

Current result:

ERROR 1510 (HY000):

REORGANIZE PARTITION can only be used to reorganize partitions

not to change their numbers

Merging history partitions fails with the same error:

CREATE OR REPLACE TABLE t1 (x INT)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME PARTITIONS 3;

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p00 HISTORY

  );

Current result:

ERROR 1510 (HY000):

REORGANIZE PARTITION can only be used to reorganize partitions

not to change their numbers

The error is produced by the generic partitioning check in prep_alter_part_table():

if (!(tab_part_info->part_type == RANGE_PARTITION ||

      tab_part_info->part_type == LIST_PARTITION) &&

    (num_parts_new != num_parts_reorged))

{

  my_error(ER_REORG_HASH_ONLY_ON_SAME_NO, MYF(0));

  goto err;

}

SYSTEM_TIME partitioning is handled as a separate partitioning type. It is neither RANGE nor LIST, so an operation that changes the number of partitions is rejected by the generic restriction intended for HASH-like partitioning.

This restriction is unnecessary for history partitions when the server can redistribute rows using the rules of the corresponding SYSTEM_TIME rotation method.

Goals

The implementation must:

• Allow multiple history partitions to be merged.
• Allow one history partition to be split where the rotation method supports it.
• Copy every source row exactly once.
• Preserve all historical row versions.
• Preserve the CURRENT partition and its rows.
• Validate rotation-specific restrictions before modifying the table.
• Update internal history-partition pointers and rotation state.
• Avoid applying the generic equal-partition-count restriction to supported SYSTEM_TIME reorganizations.
• Preserve existing behavior for ordinary RANGE, LIST, HASH, and KEY partitioning.

Merge syntax

Multiple history partitions are merged using the existing REORGANIZE PARTITION syntax:

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p00 HISTORY

  );

All historical rows from p0 and p1 must be copied to p00.

After successful completion:

• p0 and p1 no longer exist.
• p00 contains every row previously stored in p0 or p1.
• No historical row is lost or duplicated.
• The CURRENT partition is unchanged.
• SHOW CREATE TABLE displays p00 as one HISTORY partition.
• Information Schema reports the new partition layout.

Split syntax

A history partition is split using the existing REORGANIZE PARTITION syntax:

ALTER TABLE t1

  REORGANIZE PARTITION p0

  INTO (

    PARTITION p0 HISTORY,

    PARTITION p1 HISTORY

  );

Rows from the original p0 must be distributed as evenly as possible between the resulting history partitions.

For (R) source rows and (N) destination partitions:

• Every source row must be copied to exactly one destination partition.
• The difference between the largest and smallest destination row counts should not exceed one.
• Empty destination partitions are permitted when (R < N).
• The distribution must satisfy the applicable LIMIT restriction.
• The resulting distribution must not depend on a row having a unique timestamp.

This task does not require a user-visible guarantee about which specific row is assigned to which destination partition when several valid balanced distributions exist.

Source partition list

Source partitions specified by REORGANIZE PARTITION must:

• Exist.
• Be distinct.
• Be listed in partition order.
• Form a contiguous sequence.
• All be designated HISTORY.
• Belong to the same table.
• Not include the CURRENT partition.

For this task, the supported shape changes are:

• One history partition to one history partition: rename or definition-preserving reorganization.
• Multiple history partitions to one history partition: merge.
• One history partition to multiple history partitions: split.

A many-to-many reorganization is outside the required scope unless it naturally follows from the implementation.

Destination definitions

Every destination partition created by this feature must be declared HISTORY:

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p_new HISTORY

  );

The following must be rejected:

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p_new CURRENT

  );

The operation must not:

• Create a second CURRENT partition.
• Remove the existing CURRENT partition.
• Convert historical rows into current rows.
• Convert the CURRENT partition into a HISTORY partition.
• Mix CURRENT and HISTORY partitions in one reorganization.

Partition options in destination definitions must follow the existing rules for partition options and the table's storage engine.

Plain SYSTEM_TIME

For a table without LIMIT or INTERVAL rotation, merging and splitting history partitions are permitted.

Example:

CREATE OR REPLACE TABLE t1 (

  id INT,

  value VARCHAR(100)

)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME (

  PARTITION p0 HISTORY,

  PARTITION p1 HISTORY,

  PARTITION pcur CURRENT

);

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p_history HISTORY

  );

The operation must merge all rows from p0 and p1 into p_history.

Splitting is also permitted:

ALTER TABLE t1

  REORGANIZE PARTITION p_history

  INTO (

    PARTITION p0 HISTORY,

    PARTITION p1 HISTORY

  );

Because plain SYSTEM_TIME history partitions do not have individual RANGE or LIST boundaries, rows must be distributed as evenly as possible.

LIMIT partitions

For SYSTEM_TIME LIMIT, the configured LIMIT is the maximum permitted size of a resulting history partition for the purposes of this operation.

Example:

CREATE OR REPLACE TABLE t1 (

  id INT,

  value VARCHAR(100)

)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME LIMIT 1000 (

  PARTITION p0 HISTORY,

  PARTITION p1 HISTORY,

  PARTITION p2 HISTORY,

  PARTITION pcur CURRENT

);

A merge is allowed only if the total number of rows copied into the destination partition does not exceed the configured limit:

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p01 HISTORY

  );

Before changing the table, the server must determine whether:

rows(p0) + rows(p1) <= LIMIT

If the combined row count exceeds LIMIT, the operation must fail without modifying the table.

The decision must use an exact count suitable for enforcing the restriction. An approximate storage-engine row estimate must not be used as the final validation.

LIMIT split

Splitting a LIMIT history partition is permitted.

Example:

ALTER TABLE t1

  REORGANIZE PARTITION p0

  INTO (

    PARTITION p0a HISTORY,

    PARTITION p0b HISTORY

  );

Rows must be distributed as evenly as possible among the destination partitions.

After redistribution:

• No resulting partition may exceed LIMIT.
• Every source row must exist in exactly one destination partition.
• Empty result partitions are allowed.
• The working-history-partition state must be recalculated.
• Future history insertion must continue according to normal LIMIT rotation rules.

Splitting may therefore be used to reduce an overfilled history partition if the redistributed rows fit within the specified destination partitions.

If the number of destination partitions is insufficient to hold the source rows under LIMIT, the operation must fail atomically.

LIMIT overflow

A merge that would overflow LIMIT must be rejected.

For example, if:

• LIMIT is 1000.
• p0 contains 700 rows.
• p1 contains 600 rows.

then:

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p01 HISTORY

  );

must fail because the resulting partition would contain 1300 rows.

The operation must not:

• Partially copy rows.
• Truncate rows.
• Silently increase the table's configured LIMIT.
• Create an overfilled destination partition.
• Move excess rows into an unrelated history partition.
• Remove either source partition.

The error should explain that the resulting history partition would exceed the configured SYSTEM_TIME LIMIT.

INTERVAL partitions

Merging and splitting are not permitted for SYSTEM_TIME INTERVAL partitions in this task.

Example of an unsupported merge:

CREATE OR REPLACE TABLE t1 (

  id INT

)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME INTERVAL 1 MONTH (

  PARTITION p0 HISTORY,

  PARTITION p1 HISTORY,

  PARTITION pcur CURRENT

);

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p01 HISTORY

  );

The operation must fail because combining the partitions would change their temporal boundaries and invalidate routing and pruning metadata.

Splitting an interval partition must likewise fail:

ALTER TABLE t1

  REORGANIZE PARTITION p0

  INTO (

    PARTITION p0a HISTORY,

    PARTITION p0b HISTORY

  );

A one-to-one rename remains permitted, provided all interval boundary metadata is preserved:

ALTER TABLE t1

  REORGANIZE PARTITION p0

  INTO (

    PARTITION history_2026_01 HISTORY

  );

Per-partition interval manipulation belongs to the separate feature for per-partition STARTS and INTERVAL metadata. This task must not infer new interval boundaries automatically.

Row redistribution

Merge and split operations require copying rows.

For a merge:

1. Create the destination history partition.
2. Copy all rows from each source partition into the destination.
3. Validate that every source row was copied exactly once.
4. Install the new partition layout.
5. Remove the source partitions.

For a split:

1. Create all destination history partitions.
2. Scan the source partition.
3. Assign each source row to one destination partition.
4. Keep destination row counts balanced.
5. Validate applicable LIMIT restrictions.
6. Install the new partition layout.
7. Remove the source partition.

The redistribution algorithm must not alter:

• User-column values.
• System-versioning period values.
• Primary or unique-key values.
• Generated-column values.
• Utility-column values, if present.
• Existing historical identity.
• The logical order or visibility period of row versions.

The operation changes physical partition placement only.

Distribution stability

The split algorithm does not need to define a permanent SQL-visible ordering of rows.

However, one execution must be internally consistent:

• Every source row is read once.
• Every source row is written once.
• No row is assigned to multiple destination partitions.
• No row is omitted.
• Distribution state survives normal internal batching.
• Failure causes the entire reorganization to roll back.

Repeated execution on identical physical data may produce a different row-to-partition assignment, provided all semantic and balancing requirements are met.

Applications must not rely on a particular historical row being assigned to a particular destination partition after a balanced split.

Working history partition

SYSTEM_TIME partitioning maintains internal state identifying the history partition used for new historical rows.

After a merge, split, or rename, the implementation must rebuild this state from the new partition definition.

It must not retain a pointer or ordinal referring to a removed source partition.

For LIMIT rotation, the server must determine the valid working partition according to the normal post-operation partition order and capacity rules.

The next update or delete that creates history must:

• Insert the history row into a valid destination history partition.
• Respect LIMIT.
• Rotate normally when the active partition becomes full.
• Auto-create a partition when configured and required.
• Not access a removed physical partition.
• Not incorrectly treat the CURRENT partition as history.

Running FLUSH TABLES, evicting the table from the table cache, or restarting the server must produce the same working-partition selection.

AUTO partitions

When automatic history-partition creation is enabled, reorganization must preserve the automatic-rotation configuration.

After a successful operation:

• AUTO remains enabled.
• Existing auto-created partitions may be reorganized if they satisfy the same rules as explicit partitions.
• The next automatically created partition uses the resulting partition list and normal naming rules.
• Removed partition names must not leave stale internal references.
• Reorganization must not itself create an unnecessary automatic partition.

If a merge or split affects the working history partition, subsequent automatic rotation must continue from the resulting layout.

Current partition

The CURRENT partition is outside the scope of a history-partition merge or split.

The operation must preserve:

• The current partition's name.
• Its current-row contents.
• Its partition options.
• Its ordinal relationship to history partitions where required.
• The invariant that exactly one CURRENT partition exists.

A statement naming the current partition together with history partitions must be rejected before data copying begins.

Existing support for a one-to-one rename of a current partition, if any, is not changed by this task.

Algorithms

A one-to-one partition rename may continue to use the existing fast path when supported.

Merging or splitting requires row movement and must use a copy-capable algorithm.

If the statement explicitly requests an algorithm that cannot redistribute rows, the operation must fail with the standard unsupported-algorithm error.

For example:

ALTER TABLE t1

  ALGORITHM=COPY,

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p01 HISTORY

  );

must use the copy path.

An explicitly requested non-copy algorithm must not silently perform a full copy if MariaDB's normal ALTER algorithm contract prohibits such fallback.

The operation should copy only the affected partitions where the storage engine and partitioning layer support partial partition reorganization.

Locking

The operation must acquire sufficient locking to guarantee a consistent source row set and partition layout.

During merge or split:

• Concurrent DML must not insert history into a partition after that partition has been copied.
• No source row may be missed because it was inserted concurrently.
• No source row may be copied twice.
• The working history partition must not rotate concurrently with final layout installation.
• Automatic partition creation must not race with the reorganization.
• The CURRENT partition must remain consistent with history generated by concurrent DML.

If online execution cannot satisfy these requirements, the server must use the appropriate stronger lock.

An unsupported explicit LOCK request must produce the normal error rather than silently weakening consistency.

Atomicity

The reorganization must be atomic.

On success:

• All destination partitions exist.
• All source rows exist exactly once in destination partitions.
• Source partitions no longer exist.
• Partition metadata describes the destination layout.
• The working-history-partition state references a valid partition.
• The CURRENT partition remains intact.

On failure:

• All source partitions remain available.
• All source rows remain unchanged.
• No destination partition is visible.
• The original working-history-partition state remains valid.
• The original table definition remains in effect.

An error during copying, index creation, metadata installation, source removal, or DDL-log processing must not leave a partially reorganized table.

Crash recovery

The operation must be crash-safe.

A crash during any of the following stages must recover to either the original layout or the completed layout:

• Destination partition creation.
• Source-row scanning.
• Destination-row insertion.
• Index construction.
• Destination installation.
• Source partition removal.
• Partition-file rename.
• DDL-log processing.
• Table-definition update.
• Working-partition-state update.

Recovery must not produce:

• Both source and destination copies visible simultaneously.
• Missing history rows.
• Duplicate history rows.
• An invalid partition count.
• More than one CURRENT partition.
• A stale reference to a removed history partition.

Keys and constraints

All indexes and constraints must remain valid after redistribution.

The copy path must preserve or rebuild:

• Primary keys.
• Unique keys.
• Secondary indexes.
• Generated-column indexes.
• Full-text indexes where supported.
• Spatial indexes where supported.
• Foreign-key metadata according to normal partitioned-table rules.
• System-versioning index extensions.
• Utility-column index extensions, if present.

A duplicate-key or constraint error during copying must fail the complete reorganization and preserve the source layout.

Partition options

Destination partitions may specify partition options supported by ordinary REORGANIZE PARTITION and the selected storage engine.

The server must validate options before destructive changes.

Unsupported or incompatible options must cause atomic failure.

A merge or split must not silently change table-level properties such as:

• Storage engine.
• Character set.
• Collation.
• Encryption state.
• Row format.
• System-versioning mode.

Any permitted partition-level option conversion must follow existing copy-based partition reorganization rules.

SHOW CREATE TABLE

After a successful merge, SHOW CREATE TABLE must display the destination history partition and omit the removed source partitions.

For example:

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p01 HISTORY

  );

SHOW CREATE TABLE t1;

The output must contain:

PARTITION `p01` HISTORY

and must not contain p0 or p1 as separate partitions.

After a split, SHOW CREATE TABLE must display every destination history partition in the requested order.

The output must preserve:

• LIMIT, when present.
• INTERVAL, when present for a supported rename.
• AUTO, when enabled.
• The CURRENT partition.
• Destination partition names and options.

Information Schema

INFORMATION_SCHEMA.PARTITIONS must reflect the new partition layout immediately after successful completion.

It must report:

• Destination partition names.
• Correct partition ordinals.
• HISTORY and CURRENT designations.
• Updated row-count information according to normal storage-engine semantics.
• Destination partition options.
• Preserved interval metadata for a permitted one-to-one interval-partition rename.

Removed source partitions must no longer appear.

An unsuccessful operation must leave Information Schema reporting the original layout.

CHECK TABLE

After a successful merge or split:

CHECK TABLE t1;

must not report correctly redistributed rows as misplaced.

ALTER TABLE ... CHECK PARTITION must also accept every destination partition:

ALTER TABLE t1 CHECK PARTITION p0a;

ALTER TABLE t1 CHECK PARTITION p0b;

For LIMIT partitions, validation must use the applicable history-partition rules and must not require every historical row to map to one unique partition based on its contents.

The reorganization must not hide genuine storage-engine corruption or a current row stored in a history partition.

Replication

The operation must be binary-logged as one ALTER TABLE statement.

On replicas:

• The same source partitions must be reorganized.
• Every historical row must remain represented exactly once.
• The same destination partition definitions must be installed.
• The CURRENT partition must remain unchanged.
• The resulting working-history-partition state must be valid.
• A LIMIT overflow must produce deterministic behavior.

Statement-based and row-based replication must produce logically equivalent table contents and identical partition definitions.

A replica failure must not leave a partially reorganized layout.

Backup and restore

Physical backup must preserve the completed partition layout and all redistributed rows.

Logical dump after reorganization must reproduce:

• Destination partition names.
• History/current designations.
• LIMIT, INTERVAL, and AUTO settings where applicable.
• Partition options.
• All current and historical rows.

A restored table must select a valid working history partition and continue rotation normally.

Error handling

The operation must fail without changing the table when:

• A named source partition does not exist.
• A source partition is listed more than once.
• Source partitions are not contiguous.
• Source partitions are listed out of order.
• A source partition is CURRENT.
• A destination partition is not declared HISTORY.
• A destination name is duplicated.
• A destination name conflicts with an unaffected partition.
• A merge under LIMIT would exceed the configured limit.
• A split under LIMIT does not provide enough destination capacity.
• Merge or split is requested for INTERVAL history partitions.
• The requested algorithm cannot copy rows.
• The requested lock level cannot safely perform the operation.
• A destination partition option is invalid.
• Row copying fails.
• Index or constraint creation fails.
• Disk space is exhausted.
• The statement is interrupted.
• The user lacks required privileges.

The current generic error 1510 must no longer be returned for a supported SYSTEM_TIME merge or split.

Unsupported operations should return an error that describes the actual restriction, such as:

• Merging would exceed SYSTEM_TIME LIMIT.
• Splitting or merging SYSTEM_TIME INTERVAL partitions is unsupported.
• The current partition cannot participate in history reorganization.

Privileges

The statement must retain the normal privilege requirements of ALTER TABLE ... REORGANIZE PARTITION.

No additional user-visible INSERT, DELETE, or CREATE privilege should be required merely because the implementation internally copies rows.

The user must have the required ALTER-related privileges on the partitioned table.

Compatibility

Existing successful one-to-one history-partition renames must remain supported.

For example:

ALTER TABLE t1

  REORGANIZE PARTITION p0

  INTO (

    PARTITION custom_name HISTORY

  );

The change must not alter:

• Ordinary RANGE reorganization rules.
• Ordinary LIST reorganization rules.
• HASH or KEY partition-count restrictions.
• Current-row routing.
• History-row creation.
• SYSTEM_TIME LIMIT rotation outside the reorganized partitions.
• SYSTEM_TIME INTERVAL row routing or pruning.
• AUTO behavior except for adapting to the resulting partition list.
• Temporal-query semantics.
• DELETE HISTORY behavior.
• Existing partition rename behavior.

No new SQL syntax is required.

Acceptance criteria

The task is complete when all of the following are satisfied:

• A history partition can still be renamed.
• Two or more plain SYSTEM_TIME history partitions can be merged into one.
• One plain SYSTEM_TIME history partition can be split into two or more.
• Every merge preserves all source rows.
• Every split preserves all source rows.
• A split distributes rows as evenly as possible.
• No row is lost or duplicated.
• The CURRENT partition and its rows remain unchanged.
• A LIMIT merge succeeds when the combined row count does not exceed LIMIT.
• A LIMIT merge fails atomically when the combined row count exceeds LIMIT.
• A LIMIT split succeeds when resulting partitions provide sufficient capacity.
• No resulting LIMIT partition exceeds the configured limit.
• INTERVAL merge and split are rejected.
• A one-to-one INTERVAL partition rename remains supported.
• Internal working-history-partition state is valid after every supported operation.
• Subsequent DML stores history in a valid partition.
• Automatic rotation continues correctly after reorganization.
• SHOW CREATE TABLE displays the resulting layout.
• Information Schema displays the resulting layout.
• CHECK TABLE succeeds after valid redistribution.
• Explicit unsupported algorithms and lock levels are rejected.
• Failure and interruption leave the original table unchanged.
• Crash recovery produces either the original or completed layout.
• Replication produces an equivalent table.
• Ordinary non-SYSTEM_TIME partition behavior remains unchanged.

Test coverage

Add tests covering at least:

• Existing one-to-one history-partition rename.
• Merge of two empty history partitions.
• Merge of two non-empty history partitions.
• Merge of three or more history partitions.
• Split of an empty history partition.
• Split of one row into two partitions.
• Split of an even number of rows.
• Split of an odd number of rows.
• Split into more partitions than rows.
• Split into three or more partitions.
• Verification that split row-count differences do not exceed one.
• Merge followed by split.
• Split followed by merge.
• Reorganization of the first history partition.
• Reorganization of the last history partition.
• Reorganization involving the working history partition.
• Preservation of an unaffected history partition.
• Rejection of non-contiguous source partitions.
• Rejection of out-of-order source partitions.
• Rejection when the CURRENT partition is included.
• Rejection when a destination is declared CURRENT.
• Duplicate destination names.
• Conflict with an unaffected partition name.
• Plain SYSTEM_TIME partitioning.
• SYSTEM_TIME LIMIT with an allowed merge.
• SYSTEM_TIME LIMIT with an overflowing merge.
• SYSTEM_TIME LIMIT split within capacity.
• SYSTEM_TIME LIMIT split with insufficient destination capacity.
• Future history insertion after a LIMIT merge.
• Future history insertion after a LIMIT split.
• Rotation after reorganization.
• AUTO partition creation after reorganization.
• Rejection of an INTERVAL merge.
• Rejection of an INTERVAL split.
• Successful one-to-one INTERVAL rename.
• Explicit ALGORITHM=COPY.
• Rejection of an incompatible explicit algorithm.
• Supported and unsupported explicit lock levels.
• Primary and secondary indexes.
• Unique keys.
• Generated columns.
• Invisible columns.
• Explicit system-versioning period columns.
• Implicit system-versioning period columns.
• Utility columns, when supported.
• Partition-level table options.
• Disk-full handling.
• Killed operation during row copying.
• Injected failure before destination installation.
• Injected failure after destination installation.
• Injected failure during source removal.
• Server restart during each DDL-log stage.
• SHOW CREATE TABLE after merge.
• SHOW CREATE TABLE after split.
• INFORMATION_SCHEMA.PARTITIONS after merge.
• INFORMATION_SCHEMA.PARTITIONS after split.
• CHECK TABLE after merge.
• CHECK TABLE after split.
• ALTER TABLE ... CHECK PARTITION for every destination.
• Statement-based replication.
• Row-based replication.
• Mixed-format replication.
• Logical dump and restore.
• Physical backup and restore.
• Regression tests for RANGE and LIST reorganization.
• Regression tests for HASH and KEY partition-count restrictions.

The original merge regression test must be included:

CREATE OR REPLACE TABLE t1 (x INT)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME PARTITIONS 3;

ALTER TABLE t1

  REORGANIZE PARTITION p0, p1

  INTO (

    PARTITION p00 HISTORY

  );

CHECK TABLE t1;

SHOW CREATE TABLE t1;

DROP TABLE t1;

The original split regression test must also be included:

CREATE OR REPLACE TABLE t1 (x INT)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME;

ALTER TABLE t1

  REORGANIZE PARTITION p0

  INTO (

    PARTITION p0 HISTORY,

    PARTITION p1 HISTORY

  );

CHECK TABLE t1;

SHOW CREATE TABLE t1;

DROP TABLE t1;

Documentation

Update the ALTER TABLE, partition-maintenance, and system-versioned-table documentation.

Document:

• That REORGANIZE PARTITION can merge multiple history partitions.
• That one history partition can be split into multiple history partitions.
• That split rows are distributed as evenly as possible.
• Restrictions on the source partition list.
• The requirement that all destination partitions be HISTORY.
• The prohibition on including the CURRENT partition.
• LIMIT capacity validation.
• The prohibition on merging or splitting INTERVAL history partitions.
• Continued support for one-to-one interval-partition renaming.
• Copy-algorithm and locking implications.
• Atomicity and crash-recovery behavior.
• Effects on the working history partition and automatic rotation.
• Examples of successful merge and split operations.
• Examples of rejected LIMIT overflow and INTERVAL reorganization.