I am quite confused about the last slide: Every index must support duplicate keys from different snapshots. Does this means our index(i.e, B-Tree) would be enormous to contains serveral version's key. For instance, to ensure correct search from different timestamp, the index needs to store the tuples to find the exact node which brings extra storage overhead.
Let's say transaction 1 inserts a tuple (1, 20) into a table and another transaction inserty a tuple (2, 20) into the table. Let's say the first item is the PK and you create a secondary index on the second item, then you will have two uncommitted itemy from two different transactions on the key 20...
@@meamzcs yes I got the idea of duplicated keys for secondary index. But when thing goes to MultiVersion, will multiple version affect the nodes number?
Great course. Thank u 😊
notes link in description should be 15445.courses.cs.cmu.edu/fall2022/notes/18-multiversioning.pdf instead of pointing to the slides
great beats intro
indeed 😄
50:17 Is there a database called SUBWAY?
I also need to know this!
I am quite confused about the last slide: Every index must support duplicate keys from different snapshots. Does this means our index(i.e, B-Tree) would be enormous to contains serveral version's key. For instance, to ensure correct search from different timestamp, the index needs to store the tuples to find the exact node which brings extra storage overhead.
Let's say transaction 1 inserts a tuple (1, 20) into a table and another transaction inserty a tuple (2, 20) into the table. Let's say the first item is the PK and you create a secondary index on the second item, then you will have two uncommitted itemy from two different transactions on the key 20...
@@meamzcs yes I got the idea of duplicated keys for secondary index. But when thing goes to MultiVersion, will multiple version affect the nodes number?
Have to GC ("vacuum") the indexes just like the one does the tuples themselves.