On Mon, Jul 29, 2019 at 2:52 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > Thanks for sharing that. I see they're giving that paper at VLDB next > month in LA... I hope the talk video will be published on the web. > While we've been working on a hybrid vaccum/undo design, they've built > a hybrid undo/vacuum system.
It seems that this will be in a stable release soon, so it's not pie-in-the-sky stuff. AFAICT, they have indexes that always point to the latest row version. Getting an old version always required working backwards from the latest. Perhaps the constant time recovery stuff is somewhat like Postgres heapam when it comes to SELECTs, INSERTs, and DELETEs, but much less similar when it comes to UPDATEs. This seems like it might be an important distinction. As the MVCC survey paper out of CMU [1] from a couple of years back says: "The main idea of using logical pointers is that the DBMS uses a fixed identifier that does not change for each tuple in its index entry. Then, as shown in Fig. 5a, the DBMS uses an indirection layer that maps a tuple’s identifier to the HEAD of its version chain. This avoids the problem of having to update all of a table’s indexes to point to a new physical location whenever a tuple is modified. (even if the indexed attributes were not changed)." To me, this suggests that zheap ought to make heap TIDs "more logical" than they are with heapam today (heap TIDs are hybrid physical/logical identifiers today). "Row forwarding" across heap pages is the traditional way of ensuring that TIDs in indexes are stable even in the worst case, apparently, but other approaches also seem possible. [1] http://www.vldb.org/pvldb/vol10/p781-Wu.pdf -- Peter Geoghegan
