Thanks so much for the kind words. I've no doubt oversimplified a few things, but for people who are building transactional systems, they can dig deeper into the nuance. Hopefully this gets people started and at least builds a solid foundation so if they need more detail they can dig deeper and learn from smarter people than me.
Maybe a bit of an oversimplification, but there are lots of 40 minute long videos that go into the details on MVCC. But at I high level, I think this gets you started quickly! Have fun with your database.
Good explanation. However, it would've been nice if you explained the locking mechanisms (pessimistic and optimistic locks) first before explaining MVCC.
Thanks Balwinder! MVCC is a pretty technical topic, so I worried that it wasn't comprehensive enough in a short 2 minute video. But I figure anyone looking at this is smart enough to understand it after the basic concepts are explained.
You're too kind! I will admit that I worry that I oversimplify here. After all, MVCC is a complex topic. But I think this gets the fundamentals right. That book of your will probably do a good job of clarifying the finer details.
thank you for the video! the only point i didn't get is that in either way (with mvcc or without) users need to access table some time after the transaction is commited, so what are the pros?
Thanks for sharing this! One doubt I have is will the database be strongly consistent with this? If new record version insertion is taking time, and during that, I request to read the row and get an old version, it might not be consistent.
@@cameronmcnz MVCC is optimistic right? Meaning it will check for serial equivalence at the end and abort if transactions are not serial equivalent. Or is MVCC guaranteeing that all transactions will be serial equivalent?
What if another user tries to update that same row, let's say the first user wants to add 500 to the 1000 bonus, and the second wants to add 300. Will the end value (meaning the last version of that row) be 1500, 1300 or 1800 ?
Only one of the two operations will succeed. The second one will fail as the update is attempted on stale data. A new read and update would be required for the transaction that failed.
