[MDEV-19938] Reorganize multiple history partitions Created: 2019-07-03  Updated: 2020-04-16

Status: Open
Project: MariaDB Server
Component/s: Partitioning, Versioned Tables
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Aleksey Midenkov Assignee: Aleksey Midenkov
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-17554 Auto-create history partitions for sy... Closed
relates to MDEV-19903 Setup default partitions for system v... Closed

 Description   

Implement merging of multiple history partitions by the syntax:

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 p0 history);

Consider implementing splitting into multiple history partitions:

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);

Splitting distributes rows equally between specified partitions.

For INTERVAL:
Merging and splitting is forbidden.

For LIMIT:
Merging is forbidden when LIMIT is overflown.

Currently splitting and merging fail with error:

ERROR 1510 (HY000): REORGANIZE PARTITION can only be used to reorganize partitions not to change their numbers

More observations



 Comments   
Comment by Sergei Golubchik [ 2019-07-08 ]

I don't understand.

create or replace table t1 (x int) with system versioning partition by system_time partitions 3;

Does it mean that p1 is not used at all? Why is it allowed then?
With INTERVAL one cannot split or reorganize partitions, it'll break the interval logic.
So LIMIT seems to be the only use case when such reorganization could make sense.

Comment by Aleksey Midenkov [ 2020-04-16 ]

The use case for merging/splitting is when switching from INTERVAL to LIMIT. Yes, the use of `PARTITIONS 3` is not evident without INTERVAL/LIMIT though might be useful to quickly drop current history (after maybe backed up).

Generated at Thu Feb 08 08:55:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.