> Reduced maintenance needs. OrioleDB implements the concepts of undo log and page-mergins, eliminating the need for dedicated garbage collection processes. Additionally, OrioleDB implements default 64-bit transaction identifiers, thus eliminating the well-known and painful wraparound problem.
On of the major differences between Oracle and Postgres was this - Postgres kept old versions of rows around to be vacuumed, while Oracle moves them to "undo segment". So they are copying the Oracle design.
That has its own set of tradeoffs - if you're running a long transaction with higher level of serialization, the database has to look for old data in the undo segment which is not only likely vastly slower than normal table, but might not even have the data anymore (any ETL developer have probably seen "Snapshot too old" error from Oracle).
It probably is better tradeoff for some workloads, like high volume of updates with no long-running transactions, but it is more of a different design choice than a "fix" by itself.
> That has its own set of tradeoffs - if you're running a long transaction with higher level of serialization, the database has to look for old data in the undo segment which is not only likely vastly slower than normal table, but might not even have the data anymore (any ETL developer have probably seen "Snapshot too old" error from Oracle).
I would say "Snapshot too old" isn't essential drawback of undo log. DBMS can keep the the undo log records until all snapshots, which needs them, are released. And this is how OrioleDB behaves. This is also kind of "bloat", but cleanup is cheaper. You just have to cut unclaimed undo log instead of expensive vacuum.
Isn't the goal to have multiple storage engines, so you could use the one that best fits your needs? Current storage engine probably won't be removed when this is merged.
I love this, no more vacuums?