Re: MVCC and all that...

On Tue, Sep 9, 2025 at 11:57 AM Ellen Allhatatlan <
ellenallhatatlan(at)gmail(dot)com> wrote:

> > Note: your link is wrong, corrected here:
>
> Extra hyphen - sorry about and thanks for pointing it out!
>
> > What the article is driving at is that postgres does not use rollback
> logs to handle updated records in the MVCC implementation. There are
> absolutely performance tradeoffs in that decision and, if you do a lot of
> development against postgresql, those tradeoffs should influence how you
> design databases. The author then cherry picked the 'worst case' case,
> large unconstrained updates.
>
> Hmm... I was wondering about that - even though he stressed that there
> was (paraphrasing) no right or wrong - just different design
> decisions!
>
> > The article is a bit of a cheezy dig on postgres. Another example is
> the complaint about autonomous transactions with another cherry picked
> example to make postgres look back. In the real world, these would not
> matter much, and can be worked around (if you want to see my take on how to
> deal with it, see here: https://github.com/leaselock/pgasync)
>
> OK - so, I was wrong in my original assumption that somehow (and it
> wasn't simply because of the phraseology - sweep vs vacuum) I thought
> that PG and FB had a similar MVCC implementation vs. Oracle and MySQL
> (InnoDB) (and OrioleDB). I'll do a deep dive into their docco and see
> what they actually do! I'm actually very interested in the
> benchmarking side of database technology - but I do know the old adage
> - there are lies, damned lies, statistics and *_then_* there are
> database benchmarks (as seen with the link I posted!).
>

Sure. I think you'll find that postgres approach to MVCC is somewhat
unusual relative to other players in this space, which is to write 'old'
records or changes in a rollback log; if the transaction commits it is
discarded but if it rolls back, the rollback log is written back to the
heap. This makes rollbacks potentially very painful. I suspect the
postgres approach can also do better in cases of highly contended records,
but that's just a guess.

For small (one or a small number of records) updates, the approach doesn't
make a whole lot of difference especially if you are aware of and exploit
HOT. For very large updates however, it absolutely does, and one might try
to avoid them using various strategies. I very much appreciate fast
rollbacks though.

merlin

merlin