[jayflux]

> zheap will prevent bloat (a) by allowing in-place updates in common cases and (b) by reusing space as soon as a transaction that has performed a delete or non-in-place update has committed

I’m not going to pretend to understand all of this, but is there not a trade off here? Is MVCC not fast and concurrent because it does create new rows instead of trying to mutate the old/current ones, would it be slower writes?

In other words, are we sacrificing speed for less storage consumption?

[amitkapila]

It appears like we are sacrificing speed in some cases, but it is not actually true. In the current heap, we have to modify a current row, add a new row, and then WAL log diff of both rows (or in some cases need to write both rows) and routinely perform Hot-pruning. Now, when the new row can't fit on the same page, we have to write both the pages, the page which contains old row and the page that contains new row.

In zheap, we need to write an old row in undo, but in many cases, it won't be written to disk as undo worker will discard the undo very quickly unless there are open snapshots. In this, we don't need to perform Hot-pruning. So, there is an additional cost of memory copy, but that is more than compensated by savings.

You can read 'macdice' reply in this regards.