Per-partition INTERVAL for history partitions

Summary

Support different rotation intervals for individual SYSTEM_TIME history partitions.

The feature must allow:

• Changing the rotation interval for future history partitions without rebuilding or redefining completed history partitions.
• Storing the effective STARTS value and INTERVAL for every history partition.
• Explicitly specifying STARTS and INTERVAL for individual history partitions in CREATE TABLE.
• Applying a changed interval to unused explicitly declared partitions.
• Applying the current interval to history partitions created automatically by AUTO.
• Displaying effective per-partition interval metadata in SHOW CREATE TABLE and INFORMATION_SCHEMA.PARTITIONS.
• Using per-partition boundaries for row routing, partition pruning, validation, and partition maintenance.

Rationale

SYSTEM_TIME INTERVAL partitioning currently describes the history rotation schedule using one table-level start timestamp and one interval.

For example:

CREATE TABLE t1 (

  id INT,

  value VARCHAR(100)

)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME

  INTERVAL 1 YEAR

  STARTS '2020-01-01 00:00:00'

  AUTO;

A table may initially use yearly history partitions but later require smaller partitions because its workload has become more write-intensive. Future partitions may, for example, cover six months instead of one year.

This is similar to maintaining an ordinary time-based RANGE-partitioned table. Definitions and boundaries of existing partitions remain fixed, but they do not permanently determine the boundaries of partitions that will be created in the future. A DBA can retain the old yearly partitions and begin creating six-month partitions from a selected transition point.

The same operation should be possible for SYSTEM_TIME INTERVAL partitioning:

ALTER TABLE t1

  PARTITION BY SYSTEM_TIME

  INTERVAL 6 MONTH

  STARTING FROM NOW();

The statement changes the rotation schedule from the evaluated transition timestamp onward.

It must not reinterpret, resize, rebuild, or move rows from existing partitions. Existing partitions retain their original effective start timestamps, intervals, and boundaries.

The new interval applies to:

• Unused explicitly declared history partitions whose ranges begin at or after the transition point.
• History partitions subsequently created by AUTO.
• Future rotation after the transition point.

For example, a table may contain:

• Yearly history partitions covering 2020 through 2025.
• Six-month history partitions beginning at the transition point in 2026.
• One CURRENT partition.
• A table-level active interval of six months for future automatic rotation.

A single global STARTS and INTERVAL pair cannot correctly describe this table. Recalculating all boundaries from the latest interval would incorrectly reinterpret the existing yearly partitions.

The server must therefore preserve the effective start timestamp and interval for every history partition.

This metadata is required for:

• Correct row routing.
• Temporal partition pruning.
• Misplaced-row validation.
• Partition maintenance.
• SHOW CREATE TABLE round trips.
• Logical backup and restore.
• Replication.
• Information Schema inspection.

SHOW CREATE TABLE must expose both the old and new schedules. It must show the retained interval of each existing history partition and the active interval used for future partitions.

INFORMATION_SCHEMA.PARTITIONS must likewise expose the effective STARTS value and INTERVAL for every history partition. It must be possible to determine which partitions use the old schedule, which use the new schedule, and which interval will be used for future automatic partitions.

The transition timestamp must be evaluated once when the ALTER TABLE statement begins and stored as a concrete value. It must not remain as the expression NOW() in persistent metadata.

Using one evaluated timestamp is required so that:

• The transition has one deterministic boundary.
• SHOW CREATE TABLE displays a stable definition.
• Replicas do not evaluate NOW() at different times.
• Backup and restore reproduce the same partition boundaries.
• Server restart does not change the transition point.

The operation must reject a transition point that would split a non-empty existing history partition, create overlapping ranges, or leave an uncovered gap. It must not silently change the boundaries of a partition containing history.

This design allows partition granularity to evolve with the workload while preserving existing history and keeping all physical partition boundaries explicit and inspectable.

Terminology

For this task:

• A completed history partition is a history partition that is no longer the target for newly generated history.
• A working history partition is the partition currently receiving new historical rows.
• An unused history partition is an explicitly declared history partition that has not received historical rows and is reserved for future rotation.
• A retained partition is an existing partition whose effective boundaries are preserved by an interval change.
• The active rotation interval is the interval used for unused and subsequently auto-created history partitions.
• A partition's effective start is its inclusive lower temporal boundary.
• A partition's effective end is calculated from its effective start and interval and is normally its exclusive upper temporal boundary.
• The transition point is the concrete timestamp at which the new active interval begins.

Per-partition syntax

Allow STARTS and INTERVAL after an explicitly declared HISTORY partition:

CREATE TABLE t1 (

  id INT,

  value VARCHAR(100)

)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME AUTO (

  PARTITION p2020 HISTORY

    STARTS '2020-01-01 00:00:00'

    INTERVAL 1 YEAR,

  PARTITION p2021 HISTORY

    STARTS '2021-01-01 00:00:00'

    INTERVAL 1 YEAR,

  PARTITION p2022_h1 HISTORY

    STARTS '2022-01-01 00:00:00'

    INTERVAL 6 MONTH,

  PARTITION p2022_h2 HISTORY

    STARTS '2022-07-01 00:00:00'

    INTERVAL 6 MONTH,

  PARTITION pcur CURRENT

);

The grammar can be represented as:

history_partition_definition:

    PARTITION partition_name HISTORY

      [STARTS start_expression]

      [INTERVAL interval_expression interval_unit]

      [partition_options]

STARTS and INTERVAL are permitted only for HISTORY partitions of a table partitioned by SYSTEM_TIME INTERVAL.

They are not permitted for:

• The CURRENT partition.
• SYSTEM_TIME LIMIT partitioning.
• Ordinary RANGE, LIST, HASH, or KEY partition definitions.
• Subpartitions.

Table-level defaults

The existing table-level syntax remains supported:

CREATE TABLE t1 (

  id INT

)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME

  INTERVAL 1 MONTH

  STARTS '2025-01-01 00:00:00'

  AUTO (

    PARTITION p0 HISTORY,

    PARTITION p1 HISTORY,

    PARTITION pcur CURRENT

  );

The table-level STARTS and INTERVAL act as defaults for history partitions that do not explicitly specify their own values.

For each explicitly listed history partition:

• An explicit partition-level STARTS overrides the inherited start.
• An explicit partition-level INTERVAL overrides the table-level interval.
• If STARTS is omitted, it is derived from the effective end of the preceding history partition.
• If INTERVAL is omitted, the active table-level interval is inherited.
• The first history partition must have an explicit or inherited effective start.
• Every history partition must have a complete effective start and interval after inheritance is resolved.

The server must store the resolved effective values for every history partition.

Mixed intervals

Different history partitions may use different intervals in the same table.

For example:

CREATE TABLE t1 (

  id INT

)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME AUTO (

  PARTITION p2024 HISTORY

    STARTS '2024-01-01'

    INTERVAL 1 YEAR,

  PARTITION p2025q1 HISTORY

    STARTS '2025-01-01'

    INTERVAL 3 MONTH,

  PARTITION p2025q2 HISTORY

    STARTS '2025-04-01'

    INTERVAL 3 MONTH,

  PARTITION pcur CURRENT

);

The resulting history ranges are:

A row's historical version boundary must be compared with the effective boundaries of individual partitions rather than boundaries reconstructed from one global interval.

Boundary rules

The effective ranges of history partitions must be ordered and contiguous.

For consecutive history partitions pN and pN+1:

effective_start(pN+1) = effective_end(pN)

The effective end is calculated using MariaDB's existing interval arithmetic:

effective_end = effective_start + effective_interval

The following definitions must be rejected:

• Overlapping history intervals.
• Gaps between consecutive history intervals.
• History partitions listed in non-chronological order.
• A zero or negative interval.
• An unsupported interval expression or unit.
• A start timestamp outside the supported system-versioning range.
• An interval whose end cannot be represented.
• A CURRENT partition placed inside the history partition sequence.
• More than one CURRENT partition.

The last history partition may retain existing special behavior for version boundaries beyond its nominal upper boundary when no later history partition is available. This does not change its stored effective STARTS or INTERVAL.

ALTER syntax

Allow the active rotation interval to be changed from an explicit transition point:

ALTER TABLE t1

  PARTITION BY SYSTEM_TIME

  INTERVAL 6 MONTH

  STARTING FROM NOW();

The STARTING FROM expression must be evaluated once during execution and persisted as a concrete timestamp.

The grammar can be represented as:

ALTER TABLE table_name

  PARTITION BY SYSTEM_TIME

  INTERVAL interval_value interval_unit

  [STARTING FROM datetime_expression]

If STARTING FROM is omitted, the new interval starts at the effective end of the last retained history partition.

If it is specified:

• Existing partitions ending before or at the transition point remain unchanged.
• The transition point must match a valid boundary after the last retained partition.
• Unused partitions beginning at or after the transition point are recalculated using the new interval.
• Future automatically created partitions use the new interval.
• NOW() and other permitted expressions are evaluated once.
• The resolved timestamp, not the expression, is stored and replicated.
• The statement fails if the transition would split a non-empty partition or create a gap or overlap.

ALTER transition point

The server must determine the transition point between the retained schedule and the new schedule.

The following rules apply:

• Completed history partitions are always retained.
• A working history partition containing rows retains its current effective start, interval, and end.
• An empty working history partition may be treated as unused and updated to the new schedule.
• Every unused history partition after the last retained partition receives the new interval.
• The default start of the new schedule is the effective end of the last retained history partition.
• If no history partition is retained, existing default STARTS calculation applies.
• An explicitly supplied STARTING FROM timestamp must produce a valid continuation of the retained history range.

The interval change must not reinterpret rows already stored in a retained partition.

Updating unused partitions

Every unused explicitly declared history partition must adopt the new interval.

For example, assume:

• p0 and p1 are completed.
• p2 is the working partition and contains rows.
• p3 and p4 are unused.
• The current interval is one year.

After:

ALTER TABLE t1

  PARTITION BY SYSTEM_TIME

  INTERVAL 1 MONTH;

the expected behavior is:

• p0 retains its original start and one-year interval.
• p1 retains its original start and one-year interval.
• p2 retains its original start and one-year interval.
• p3 starts at the effective end of p2 and receives a one-month interval.
• p4 starts at the effective end of p3 and receives a one-month interval.
• The next auto-created partition starts at the effective end of p4 and receives a one-month interval.

Unused partitions must not retain a stale interval merely because they were declared before the ALTER TABLE statement.

Automatic partitions

When AUTO is enabled, every newly created history partition must use the active rotation interval in effect when that partition is created.

The new partition must store:

• Its effective start.
• Its effective interval.
• Its calculated upper boundary.
• Its history-partition designation.

Changing the active interval must not modify automatically created partitions that are already completed or contain history.

A partition created after the change must not derive its boundaries using an interval belonging to an older partition.

For example:

ALTER TABLE t1

  PARTITION BY SYSTEM_TIME

  INTERVAL 1 MONTH

  STARTING FROM NOW();

All subsequently auto-created partitions use 1 MONTH.

Restarting the server, rebuilding the table cache, or executing DDL must not lose the active interval or any partition's effective interval metadata.

Row routing

Historical rows must be routed according to the effective range of each history partition.

For a history partition with:

STARTS S

INTERVAL I

the normal range is:

S <= version_boundary < S + I

The implementation must locate the correct history partition across a sequence containing different interval units and lengths.

It must support mixtures such as:

• Years followed by months.
• Months followed by days.
• Weeks followed by days.
• Different positive quantities of the same interval unit.
• Calendar intervals with variable physical durations.

The implementation must use calendar-aware interval arithmetic. It must not convert months or years to fixed numbers of seconds.

The CURRENT partition continues to receive current row versions.

Partition pruning

Temporal partition pruning must use each partition's stored effective boundaries.

For example:

SELECT *

FROM t1

FOR SYSTEM_TIME

FROM '2025-02-01' TO '2025-03-01';

The optimizer must select only partitions whose effective ranges may intersect the requested system-time range.

Pruning must remain correct when:

• Adjacent partitions have different intervals.
• Interval units differ.
• The table interval has been changed one or more times.
• Old and new schedules coexist.
• Partitions were created explicitly.
• Partitions were created automatically.
• The final history partition temporarily accepts rows beyond its nominal upper boundary.
• Prepared statements are executed after an interval-changing DDL operation.

Pruning correctness is required even if the implementation cannot use the previous constant-interval fast path.

Partition validation

CHECK TABLE and partition-placement validation must use the effective range of each interval history partition.

A historical row is correctly placed when its version boundary falls within the effective range of the partition containing it, subject to existing final-history-partition behavior.

Validation must not calculate the expected partition using:

• The latest table-level interval alone.
• The first partition's interval for the entire table.
• A partition count multiplied by one global interval.

REPAIR TABLE or equivalent misplaced-row repair must route a row using the same per-partition metadata.

SHOW CREATE TABLE

SHOW CREATE TABLE must produce a complete definition from which the per-partition schedule can be reconstructed without consulting hidden metadata.

For a table containing mixed intervals, output explicit effective metadata for each history partition:

CREATE TABLE `t1` (

  `id` int(11)

) WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME

INTERVAL 1 MONTH

AUTO (

  PARTITION `p2024` HISTORY

    STARTS TIMESTAMP'2024-01-01 00:00:00'

    INTERVAL 1 YEAR,

  PARTITION `p2025q1` HISTORY

    STARTS TIMESTAMP'2025-01-01 00:00:00'

    INTERVAL 3 MONTH,

  PARTITION `p2025q2` HISTORY

    STARTS TIMESTAMP'2025-04-01 00:00:00'

    INTERVAL 3 MONTH,

  PARTITION `pcur` CURRENT

);

The table-level interval represents the active default for unused and future automatically created partitions.

The partition-level clauses represent effective metadata of existing history partitions.

After an interval-changing ALTER TABLE:

• Retained partitions must continue to show their previous effective intervals.
• Affected unused partitions must show the new interval.
• The table-level clause must show the new active interval.
• Dumping and restoring the output must reproduce the same partition boundaries and active schedule.

SHOW CREATE TABLE may omit redundant per-partition values only if the output remains unambiguous and round-trips to exactly the same effective metadata. Canonical output should prefer explicit values for mixed schedules.

Information Schema

INFORMATION_SCHEMA.PARTITIONS must display the effective interval and start timestamp for each HISTORY partition.

Add fields equivalent to:

For a CURRENT partition, these fields are NULL.

For non-SYSTEM_TIME INTERVAL partitions, these fields are NULL.

PARTITION_DESCRIPTION must continue to expose the effective upper boundary of an interval history partition.

The following relationship must hold for ordinary interval history partitions:

PARTITION_DESCRIPTION =

  PARTITION_STARTS +

  PARTITION_INTERVAL_VALUE PARTITION_INTERVAL_UNIT

subject to maximum-timestamp handling for the final history partition.

Information Schema must display effective values after inheritance. It must not return NULL merely because a value was inherited from the table-level default.

Metadata persistence

The table definition must persist, for each history partition:

• Effective start timestamp.
• Effective interval value.
• Effective interval unit.
• Effective upper boundary.
• Whether the partition is HISTORY or CURRENT.

The table definition must also persist:

• The active interval value.
• The active interval unit.
• The concrete transition point of the latest schedule change, where applicable.
• Whether automatic partition creation is enabled.

Metadata must survive:

• Server restart.
• Table cache eviction.
• Crash recovery.
• FLUSH TABLES.
• Table rename.
• Database rename where supported.
• Copy-based and in-place table rebuilds.
• Backup and restore.
• Binary-log replication.

Opening a table must not reconstruct old partition intervals from only the current active interval.

Partition maintenance

Per-partition interval metadata must be handled correctly by:

• ADD PARTITION.
• DROP PARTITION.
• REORGANIZE PARTITION.
• CONVERT PARTITION ... TO TABLE.
• CONVERT TABLE ... TO PARTITION.
• EXCHANGE PARTITION where applicable.
• TRUNCATE PARTITION.
• Table rebuilds.
• Storage-engine conversion.
• Automatic history-partition creation.

Dropping old history partitions must not shift or recalculate the effective boundaries of remaining partitions.

When the first history partition is dropped:

• The next partition retains its existing effective start and interval.
• The active interval remains unchanged.
• SHOW CREATE TABLE and Information Schema continue to expose the retained effective values.

Adding a history partition explicitly must validate its effective start and interval against adjacent partitions.

ALTER atomicity

Changing the active interval and updating unused partition metadata must be atomic.

On success:

• Retained partition metadata is unchanged.
• Every affected unused partition has the new effective interval.
• The active interval is updated.
• Subsequent automatic partitions use the new interval.

On failure:

• The old active interval remains in effect.
• No partition has partially updated metadata.
• No automatically created partition is left behind.
• No rows are moved.
• The original table definition remains usable.

Crash recovery must produce either the complete old definition or the complete new definition.

Locking

An interval-changing ALTER TABLE must acquire sufficient metadata locking to prevent concurrent rotation from changing an unused partition into a used partition while its metadata is being updated.

The implementation must consistently determine:

• Which partitions are retained.
• Which partition is currently working.
• Which partitions are unused.
• The transition boundary.
• Whether automatic creation is required.

Concurrent DML must not insert a history row using a partially updated rotation schedule.

If the operation is metadata-only, it should avoid stronger locking than required for correctness. Unsupported LOCK or ALGORITHM requests must produce the normal error instead of silently weakening consistency.

Time-zone handling

Effective partition timestamps must be stored in a time-zone-independent canonical form.

Input values are interpreted using existing STARTS rules and the session time zone.

SHOW CREATE TABLE and Information Schema must produce stable and unambiguous values.

Changing the session or global time zone must not alter:

• Physical partition boundaries.
• Row routing.
• Partition pruning.
• The transition between interval schedules.

Daylight-saving transitions must use the same timestamp conversion and interval arithmetic as existing SYSTEM_TIME INTERVAL partitioning.

Replication

The complete per-partition schedule must replicate deterministically.

Statement-based and row-based replication must preserve:

• Every partition's effective start.
• Every partition's effective interval.
• The active interval.
• The transition between old and new schedules.
• Automatic partition creation behavior.

An interval-changing ALTER TABLE must be written to the binary log as one DDL statement.

Replicas must not recalculate omitted values using their own execution timestamp, session time zone, or current clock. The binary-logged or persisted definition must contain enough resolved information to reproduce the primary's boundaries.

Replication failure must not leave a partially changed schedule.

Backup and restore

Physical backup must preserve all stored per-partition metadata.

Logical dump must use syntax that reproduces:

• Existing mixed partition intervals.
• Effective starts.
• Effective upper boundaries.
• The active future interval.
• AUTO behavior.

Restoring a dumped table must not recalculate old partition boundaries from the active interval.

A SHOW CREATE TABLE round trip must result in an equivalent definition:

SHOW CREATE TABLE t1;

-- Execute the returned definition under another table name.

SELECT

  PARTITION_NAME,

  PARTITION_DESCRIPTION,

  PARTITION_STARTS,

  PARTITION_INTERVAL_VALUE,

  PARTITION_INTERVAL_UNIT

FROM information_schema.PARTITIONS

WHERE TABLE_SCHEMA = DATABASE()

  AND TABLE_NAME IN ('t1', 't1_copy')

ORDER BY TABLE_NAME, PARTITION_ORDINAL_POSITION;

The corresponding partition metadata must be equivalent.

Error handling

The server must reject:

• A partition-level interval on a CURRENT partition.
• A partition-level interval on a non-versioned table.
• A partition-level interval for SYSTEM_TIME LIMIT.
• Zero or negative intervals.
• Unsupported interval types.
• Non-constant interval or start expressions.
• An invalid or out-of-range start timestamp.
• An interval whose end overflows the supported timestamp range, except where existing final-partition handling applies.
• Overlapping effective ranges.
• A gap between effective ranges.
• Partitions listed in non-chronological order.
• A STARTING FROM value that is inconsistent with the retained schedule.
• A STARTING FROM value that splits a non-empty existing history partition.
• Changing metadata of a retained non-empty partition.
• An interval change that cannot be persisted atomically.
• Unsupported storage engines or ALTER algorithms.

Errors must leave table rows, partition metadata, and the active interval unchanged.

Compatibility

Existing definitions using one global interval must remain valid:

CREATE TABLE t1 (

  id INT

)

WITH SYSTEM VERSIONING

PARTITION BY SYSTEM_TIME

  INTERVAL 1 MONTH

  STARTS '2025-01-01'

  AUTO;

For such tables:

• All generated history partitions initially inherit the same interval.
• Existing routing and pruning results remain unchanged.
• SHOW CREATE TABLE remains executable.
• Existing dump files remain importable.
• No manual migration is required.

The feature must not change:

• SYSTEM_TIME LIMIT semantics.
• Non-versioned partitioning.
• Transaction-precise versioning restrictions.
• Current-row placement.
• Temporal query syntax.
• History retention or DELETE HISTORY semantics.
• Existing AUTO behavior except for its use of the active interval.

Acceptance criteria

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

• Different history partitions can have different effective intervals.
• Explicit STARTS and INTERVAL can be assigned to individual history partitions.
• Omitted partition-level values inherit correct effective defaults.
• Mixed interval definitions reject gaps and overlaps.
• ALTER TABLE can change the future rotation interval without rebuilding completed history partitions.
• STARTING FROM NOW() is evaluated once and persisted as a concrete timestamp.
• Completed and non-empty working partitions retain their original metadata.
• Every unused explicitly declared history partition receives the new interval.
• Every subsequently auto-created history partition receives the new interval.
• Existing rows remain in their original retained partitions.
• Row routing works across old and new schedules.
• Temporal partition pruning works across old and new schedules.
• CHECK TABLE validates rows using per-partition boundaries.
• Dropping an old partition does not recalculate remaining boundaries.
• SHOW CREATE TABLE displays effective mixed schedules.
• SHOW CREATE TABLE displays the new active interval after ALTER.
• INFORMATION_SCHEMA.PARTITIONS exposes effective STARTS and INTERVAL for each history partition.
• Logical dump and restore preserve the complete schedule.
• Statement-based and row-based replication produce equivalent metadata.
• Server restart and table cache reload preserve all effective values.
• Failed or interrupted ALTER leaves the old schedule intact.
• Existing single-interval tables remain compatible.

Test coverage

Add tests covering at least:

• Existing global INTERVAL syntax.
• Existing global STARTS syntax.
• Explicit per-partition STARTS.
• Explicit per-partition INTERVAL.
• Explicit per-partition STARTS and INTERVAL together.
• Inheritance of the table-level interval.
• Inheritance of start from the preceding partition.
• Several different interval quantities.
• Several different interval units.
• Year-to-month transition.
• Month-to-day transition.
• Calendar-month boundaries.
• Leap years.
• Daylight-saving transitions.
• Fractional timestamp precision where supported.
• Invalid zero interval.
• Invalid negative interval.
• Invalid start timestamp.
• Boundary overflow.
• Overlapping intervals.
• A gap between intervals.
• Non-chronological partition order.
• Partition-level interval on CURRENT.
• Partition-level interval with SYSTEM_TIME LIMIT.
• ALTER TABLE ... STARTING FROM NOW().
• Verification that NOW() is evaluated once.
• Replication of a resolved STARTING FROM NOW() timestamp.
• ALTER with only completed partitions.
• ALTER with a non-empty working partition.
• ALTER with an empty working partition.
• ALTER with several unused explicit partitions.
• Verification that all unused partitions receive the new interval.
• Rejection when STARTING FROM splits a non-empty history partition.
• Auto-created partitions before the interval change.
• Auto-created partitions after the interval change.
• Several consecutive interval changes.
• Row routing to partitions from different schedules.
• FOR SYSTEM_TIME AS OF pruning.
• FOR SYSTEM_TIME FROM ... TO pruning.
• FOR SYSTEM_TIME BETWEEN ... AND pruning.
• Prepared temporal statements executed after ALTER.
• CHECK TABLE with mixed intervals.
• Misplaced-row repair with mixed intervals.
• ADD PARTITION.
• DROP PARTITION.
• REORGANIZE PARTITION.
• Partition conversion.
• Partition exchange where supported.
• TRUNCATE PARTITION.
• Copy-based table rebuild.
• Storage-engine conversion.
• Server restart.
• Table cache eviction.
• Injected ALTER failure.
• Crash recovery during interval-changing ALTER.
• Statement-based replication.
• Row-based replication.
• Mixed-format replication.
• Logical dump and restore.
• Physical backup and restore.
• SHOW CREATE TABLE round trip.
• Information Schema values before and after ALTER.
• Backward compatibility with an existing single-interval table.

Documentation

Update the system-versioned-table, partitioning, CREATE TABLE, ALTER TABLE, and Information Schema documentation.

Document:

• Per-partition STARTS and INTERVAL syntax.
• Inheritance from table-level defaults.
• Effective start and end boundary rules.
• Requirements for contiguous and ordered history ranges.
• How to change the interval for future partitions.
• STARTING FROM semantics and single evaluation of NOW().
• Which existing partitions are retained during ALTER.
• Treatment of empty and non-empty working partitions.
• Application of the new interval to unused partitions.
• Application of the new interval to auto-created partitions.
• The distinction between per-partition metadata and the active future interval.
• SHOW CREATE TABLE representation.
• New INFORMATION_SCHEMA.PARTITIONS fields.
• Pruning and routing behavior for mixed schedules.
• Time-zone and calendar-interval behavior.
• Replication, backup, and restore requirements.