Umbra: A Disk-Based System with In-Memory Performance (Thomas Neumann)
Ғылым және технология
CMU Database Group - ¡Databases! - A Database Seminar Series (2022)
Speakers: Thomas Neumann (Umbra)
September 12, 2022
db.cs.cmu.edu/seminar2022/#db1
Sponsors:
OtterTune (ottertune.com)
Google DAPA Team (google.com)
Пікірлер: 11
What a incredibly brilliant software designer/developer! This is one of the smartest software people I have ever listened to (a German version of Cliff Click maybe or Carmack?) Thank you.
Future Turing Award winner!
In the GMS switch the “Program” to Analog app 1 TE
where could get those slides
Where can we find the presentation?
There is so many different approaches in this video. And all of them seem orthogonal. I'm an engineer, I can implement anything of this in Postgres in my spare time (right now btw) and maybe even push to be commited. But not everything of these. What should I choose? Varpages, swizzling pointers, optimistic lockings..? Anything of these is simple to just prototype. But attacking any two is overly complex.
@meamzcs
Жыл бұрын
You can't really implement pointer sizzling in the same way because otherwise you'd first have to restructure everything so that basically everything is a tree.
@byterelay
Жыл бұрын
@@meamzcs just add a Buffer ptr to IndexTuple and here you go. It's not _exactly_ same technique, but close enough for prototyping.
@byterelay
Жыл бұрын
@@meamzcs I could bet a beer that I can make it working in few hours.
@meamzcs
Жыл бұрын
@@byterelay Well think about why Pointer Swizzling is done in Umbra: It's done to be able to throw out the pagetable from the buffer manager that you have to latch which is a contention point essentially... So what you would need to do for this to actually be useful in postgres is: Remove every data structure that is not a tree (because every page can only have at most one other page pointing (or a limited but small number as Prof. Neumann explained) to it so that you can go back and replace that pointer by an unswizzled reference to the page once you evict a page which means you even have to basically rewrite all btree operations because in postgres the leaf nodes are doubly linked which means almost all leaf nodes have at least 3 incoming references to them which also means you have to rewrite your tree operations and now the worst thing: A heap page can have a very high number of pages referencing it because every tuple on the page can be pointed to by a different index page so you have to rewrite the whole database to only contain index organized tables where the index (e.g. primary key index) also contains the whole tuples in the leaf pages.
@byterelay
Жыл бұрын
@@meamzcs swizzling pointer does not have to be always valid. Goint through the pointer may fail and then you fix the pointer by following BlockNo->shared_buffers lookup. When the working set fits in RAM this would work the same way.