> 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!). Thanks for your input. Best regards, El! > merlin
