Details
-
Technical task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
There should be choice between 3 modes of writing history rows:
generic Done at SQL layer. Now this mode works by default for any supported storage engine except InnoDB.
native Done at storage engine layer. Now this mode works by default for InnoDB. It is unimplemented in other storage engines.
precise This mode is currently unimplemented and it is subject of MDEV-16226. Work as native mode but update system fields row_start and row_end at commit time.
The mode affects only DML operation, the history format is identical for all 3 modes. So it should be possible to switch the table between the modes.
create or replace table t1 (x int) with system versioning engine=innodb system_versioning=native; |
alter table t1 system_versioning=precise; |
It should be possible to imply WITH SYSTEM VERSIONING just by specifying system_versioning option:
create or replace table t1 (x int) engine=innodb system_versioning=native; |
create or replace table t1 (x int) engine=myisam system_versioning=generic; |
For InnoDB all 3 modes of operation should be possible. There is slight performance advantage of native mode comparing to generic mode since history row insertion and system fields update is done in storage engine layer and this mode is subject for further performance optimization at InnoDB side. This slowest mode is precise.
Other storage engines with system versioning support can work only in generic mode.
Since partitioning works at SQL layer it is impossible to do history partitioning in native or precise mode. FIXME: maybe allow precise to work as generic for that?
Default mode is specified by system_versioning_default_mode and is generic by default.