Details
-
Task
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
None
Description
The most-common use-case for Partitioning is to allow data to "expire" using a time-expression on the partitioning expression based on some field in the table, mostly a field with some time-based information on it but sometimes this is a sequence number or similar.
The feature here is based on this notion, but is adds the feature that the data / time or partitioning expression being used doesn't have to be stored in the database itself. This does have some distinct advantages, but it also has disadvantages, but it is a useful future for the future.
The idea is that every time an INSERT into such a partitioned table is executed, the partitioning expression is determined outside the actual data being inserted. An example is the current date and time. For SELECTs the same applies, only the partitions matching the current date and time would be evaluated.
The advantage of the above is that the partitioning data doesn't have to be stored in the table data. To allow data to be processed in a partition not matching the current date and time, the FROM <table> PARTITION <partition> format.
In addition, I think that there is a need to set a session variable that contains the key to use instead of the current date and time, if set. Let's call the session variable PARTITION_KEY for now, and this really should affect both SELECT as well as INSERT/SELECT/UPDATE.
I would suggest this order of precedence:
1) if a FROM .. PARTITION clause is present, use this.
2) If the PARTITION_KEY session variable is set, then use this.
3) Else, use the current date/time
I can think of cases where we one would want to use something else that a time-based value for partitioning, but I leave this to the implementation.
An additional feature here would be to have MariaDB create partitions as needed, and also possibly drop outdated partitions by specifying how many "active" partitions one would want to keep.