I am making a document about the DML mechanism of memsql.
I understood the skiplist mechanism of insert, delete when using low store.
I think the update mechanism is internally delete, and then insert. Is it right?
And the reason I came to think this is because of the memsql document that the skiplist is performed similarly to the B-tree, and I looked at it the same as the update mechanism of the b-tree.
I think the update mechanism adds a flag to the existing data that it has been deleted and inserts new updated data.
The memory of the data that was subsequently flagged for deletion by the garbage collector is turned off.
Then, the data that has been flagged for deletion is turned off by the garbage collector.
MemSQL does multi-versioning internally for rowstore tables. If the key columns of a row aren’t changed by the update (so the row doesn’t need to move in an index), MemSQL will place a new version over top of the existing version directly (the update will be executed as as seek to the target row and then inserting a new version for that row). Otherwise, the update is implemented as a delete (the old version is marked deleted) followed by an insert (this is how the row moves within the index to its new location if some key column changed).
In either case, the old row is cleaned up by the garbage collector after the update commits. GC will either notice a deleted version or notice a stale version (a version of a row with some newer version inserted on top of it) and free it.