points by senderista 3 days ago | 0 comments
The Postgres approach to MVCC ("append-only storage" in the jargon of https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postg...) is mandatory if you actually return object addresses to the client and thus need pointer stability (I've implemented such a DB). However, Postgres doesn't actually have this requirement so it makes little sense in that context. The beauty of undo log-based MVCC is that all versions superseded by a committed transaction are freed at the same time and from the same contiguous region of memory or disk, which makes it both memory- and SSD-friendly ("grouping by death time" in the jargon of https://research.cs.wisc.edu/wind/Publications/nvmw18-he.pdf).
[–] xyzzy_plugh 3 days ago
[–] senderista 3 days ago
[–] mike_hearn 3 days ago
The simplest form of Flashback just uses the undo logs. Normally undo is deleted once no live transaction uses it, but you can set a retention time to allow SELECT ... AS OF ... queries to go back at least that far.
However, keeping undo logs around forever isn't practical. If you want to go back a year then there's Flashback Time Travel which copies old data into tables in a form that the query engine can use to answer AS OF queries more efficiently.
[–] senderista 2 days ago
I don’t know if Flashback uses this technique, but the SQL Server architect who taught me time-split B-trees now works at Oracle :)
[–] mike_hearn 2 days ago
[–] senderista 1 day ago
[–] mike_hearn 22 hours ago
[–] xyzzy_plugh 3 days ago