Details
-
Task
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
Description
As was discussed in https://mariadb.slack.com/archives/CHTLSLQEP/p1575543442067300 (attached here) transaction_registry table has many drawbacks: performance, hard to backup, not node-portable. The feature of transaction-precise versioning as described in https://mariadb.com/kb/en/library/temporal-data-tables/ actually does not require transaction_registry translation: we store timestamps as usual, but update row_end of changed rows at commit time.
Clustered index records contain DB_TRX_ID, DB_ROLL_PTR fields with non-null values in case they was changed by some open transaction. Clustered index is ordered by PK, explicit or implicit. In case there is no explicit PK in table, first non-null UK is then used or if no such UK exists then auto-generated DB_ROW_ID is added to clustered index. So there are 3 variants of ordering: explicit PK, non-null UK, DB_ROW_ID. We cannot search quickly by DB_TRX_ID.
Every open transaction has 2 undo logs attached per each changed table. Undo log cannot be attached to more than 1 transaction. One of undo logs is used for non-temporary tables, another one is for temporary ones. Non-temporary undo log must be scanned and corresponding clustered index rows selected by PK (one of 3 variants above).
Attachments
Issue Links
- is blocked by
-
MDEV-16144 Default TIMESTAMP clause for SELECT from versioned
-
- Closed
-
- relates to
-
MDEV-17089 Updating a System Versioned Table always causes a row to be updated, regardless if the data is the same or not
-
- Closed
-
-
MDEV-22540 ER_DUP_ENTRY upon REPLACE or Assertion `transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table' failed
-
- Closed
-
-
MDEV-23446 UPDATE does not insert history row if the row is not changed
-
- Closed
-
-
MDEV-20842 Crash using versioning plugin functions after plugin was removed from server
-
- Closed
-