3 ms·

It’s not really because of Amdahl’s law but because the concurrency control used by Postgres is not infinitely scalable. IIRC, Postgres uses MVCC with some modi

by slaymaker1907 7y ago

It’s not really because of Amdahl’s law but because the concurrency control used by Postgres is not infinitely scalable. IIRC, Postgres uses MVCC with some modifications to give full serializability if desired and that some of this is basically run optimistically such that it may have to abort a transaction if it cannot be committed in a serializable way. A consequence of this is that the number of aborts will grow very rapidly as you increase concurrency. A particularly nasty behavior occurs when you get into a situation where given a set of concurrent transactions, all of them must be aborted. While 2PL is not very popular these days, it does have the advantage that you can often entirely eliminate deadlock via carefully written queries. Then you just have to deal with Amdahl’s law and you won’t run into quite as catastrophic performance given high concurrency. Andy Pavlo wrote a paper looking at this comparing different concurrency control strategies under very high levels of concurrency.

ellisv 7y ago
> Andy Pavlo wrote a paper looking at this comparing different concurrency control strategies under very high levels of concurrency. I think you mean his paper "This is the Best Paper Ever on In-Memory Multi-Version Concurrency Control" which is available here: http://www.cs.cmu.edu/~pavlo/papers/p781-wu.pdf http://www.cs.cmu.edu/~pavlo/papers/p781-wu.pdf By the way, his courses are really excellent. I highly recommend subscribing to the CMU Database Group channel on YouTube.
hinkley 7y ago
The limitations of your concurrency primitives are Amhdahl's law. We call them "concurrency primitives" but they're really about shared state. They are the sequential parts of the operation. The commit phase of optimistic locking is cheap except when it's a do-over, and by necessity it causes the second action to use the resource twice, the second time sequentially to the first action.
- londons_explore 7y ago
  Are you sure about this? I'm not aware of any parts of postgres which use optimistic locking?

ellisv 7y ago

> Andy Pavlo wrote a paper looking at this comparing different concurrency control strategies under very high levels of concurrency. I think you mean his paper "This is the Best Paper Ever on In-Memory Multi-Version Concurrency Control" which is available here: http://www.cs.cmu.edu/~pavlo/papers/p781-wu.pdf http://www.cs.cmu.edu/~pavlo/papers/p781-wu.pdf By the way, his courses are really excellent. I highly recommend subscribing to the CMU Database Group channel on YouTube.

hinkley 7y ago

The limitations of your concurrency primitives are Amhdahl's law. We call them "concurrency primitives" but they're really about shared state. They are the sequential parts of the operation. The commit phase of optimistic locking is cheap except when it's a do-over, and by necessity it causes the second action to use the resource twice, the second time sequentially to the first action.

londons_explore 7y ago
Are you sure about this? I'm not aware of any parts of postgres which use optimistic locking?