3 ms·
One cool thing about the way MVCC currently works in PostgreSQL is that transaction rollback is instantaneous - there is no undo work to perform if you chose to
by balfirevic 9y ago
One cool thing about the way MVCC currently works in PostgreSQL is that transaction rollback is instantaneous - there is no undo work to perform if you chose to rollback your transaction.
This proposal seems like it would do away with that feature - but perhaps it's a good trade off in practice. I wonder what people here think.
- arkh 9y agoI like their stance on it: > This system is very much symmetric. A transaction that commits generates pretty much the same amount of work as a transaction that aborts. This is very elegant, but it’s not best in practice, because very few people run workloads where anywhere close to 50% of transactions abort. (Anyone who has such a workload will, I suspect, find that PostgreSQL handily outperforms the competition.) It would be better to have a system where we try to make commits cheaper, and aborts more expensive.
- gfisher 9y agoI agree - I know that my organization would see an increase in performance, as 90%+ of our transactions are committed. I am excited to see this in action.
- paulryanrogers 9y agoTest suites that rely on fast rollback may beg to differ