【问题描述】
请问这个transnode压缩指什么？类似于sstable的compaction？怎么保证合并时，这个版本不被依赖？
commit callback会把comit version回填到transnode上，如果一个事务修改了1000行，会回填1000个transnode？感觉比较耗时。是否可以多个行共享一个transversion位置，callback只需要修改这一个地方，所有trans node引用这一个transversion位置？
将多个transnode，如多个update整合到一个TransNode，得到一个集合了这些update的update行，和compact过程有点类似。
你这里说的版本的依赖是什么意思？首先memtable至少需要转储成mini sstable才能参与合并
版本的依赖是被压缩的版本可能会被读事务读这个版本，也是根据undo retention和收集活跃事务列表确认是否可以把这个版本压缩掉？
commit callback会把comit version回填到transnode上，如果一个事务修改了1000行，会回填1000个transnode？感觉比较耗时。是否可以多个行共享一个transversion位置，callback只需要修改这一个地方，所有trans node引用这一个transversion位置？
首先，major里面不含多版本数据，mini/minor里才有，假设说现在有6版本的major，分区的多版本保留位点是8，现在的时间是10，8版本的读能够读到数据，5版本的读是读不到数据的。
也就是说，能够读的版本，需要确保比最小的major位点大。
其次，假设现在有个8版本的读（在某活跃事务里），发生了10版本的合并，那么我们不考虑undo_retention的情况下，新的多版本保留位点依然是8，此时6版本的旧major是不能回收的，因此这个8版本的读还是可以读。也就是说我们需要保证至少有一个major是比多版本保留位点小的。
当然，多版本保留位点还和其他位点相关，这里我们简化了。