Do or undo – there is no VACUUM

Re:Do or undo – there is no VACUUM by balfirevic on Wednesday January 31, 2018 @07:42AM (#16273404)

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.

[ Parent | on HN ]

Re:Do or undo – there is no VACUUM by arkh on Wednesday January 31, 2018 @08:16AM (#16273557)

I 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.

[ Parent | on HN ]

Re:Do or undo – there is no VACUUM by gfisher on Wednesday January 31, 2018 @09:23AM (#16274015)

I 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.

[ Parent | on HN ]

Re:Do or undo – there is no VACUUM by paulryanrogers on Wednesday January 31, 2018 @02:16PM (#16276649)

Test suites that rely on fast rollback may beg to differ

[ Parent | on HN ]