[MDEV-17553] Enable setting start datetime for interval partitioned history of system versioned tables Created: 2018-10-26  Updated: 2019-11-08  Resolved: 2019-11-08

Status: Closed
Project: MariaDB Server
Component/s: Partitioning, Versioned Tables
Fix Version/s: 10.5.0

Type: Task Priority: Critical
Reporter: Ulrich Moser (Inactive) Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 1
Labels: partitioning, system_versioned_tables

Issue Links:
Relates
relates to MDEV-17554 Auto-create history partitions for sy... Closed
relates to MDEV-18535 Order of setting query timestamp brea... Open
relates to MDEV-21003 Per-partition INTERVAL for history pa... Open

 Description   

System Versioning allows storing the historical data in separate partitions partitioned by a time interval. (see https://mariadb.com/kb/en/library/system-versioned-tables/#storing-the-history-separately). This would be a helpful functionality if it were possible to set the start datatime for the interval, e.g. the start of the fiscal year. This way the data could be partitioned by fiscal year which would make it easy to drop ald partitions for which the retention time as expired. Without this interval adjustment removing old data would result in a DELETE ... WHERE ...

Proposal for syntax

CREATE TABLE t (x INT) WITH SYSTEM VERSIONING
  PARTITION BY SYSTEM_TIME INTERVAL 1 YEAR STARTS '2018-10-01 00:00:00'  (
    PARTITION p0 HISTORY,
    PARTITION p1 HISTORY,
    PARTITION p2 HISTORY,
    PARTITION pcur CURRENT
  );

Default STARTS rounding depending on INTERVAL type

If STARTS clause is omitted, a default one is assigned with value
derived from query timestamp. The rounding is done on STARTS value
depending on INTERVAL type:

SECOND: no rounding is done;
MINUTE: timestamp seconds is set to 0;
HOUR: timestamp seconds and minutes are set to 0;
DAY, WEEK, MONTH and YEAR: timestamp seconds, minutes and hours are
set to 0 (the date of rotation is kept as current date).



 Comments   
Comment by Federico Razzoli [ 2019-09-26 ]

With RANGE method, when you create a table partitioned by time, you don't write in the stone the bounds of partitions that will be created in the future. You can start by 1 year per partition, and then if the workload becomes more write-intensive, future partitions could contain 6 months of data.

So I'm suggesting to also implement this syntax:

ALTER TABLE t PARTITION BY SYSTEM_TIME INTERVAL 6 MONTH STARTING FROM NOW();

If this is implemented, I would expect to see the new and the old intervals in SHOW CREATE TABLE and information_schema.

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