←back to thread

MVCC – the part of PostgreSQL we hate the most (2023)

(www.cs.cmu.edu)
382 points virtualwhys | 2 comments | 20 Oct 24 15:30 UTC | HN request time: 0.416s | source
Show context
fweimer ◴[20 Oct 24 18:48 UTC] No.41897588[source]▶
The big advantage is that you do not need any extra space if your workload mostly consists of INSERTs (followed by table drops). And it's generally unnecessary to split up insertion transactions because there is no size limit as such (neither on the generated data or the total count of rows changed). There is a limit on statements in a transaction, but you can sidestep that by using COPY FROM if you do not have to switch tables too frequently. From a DBA point of view, there is no need to manage a rollback/undo space separately from table storage.

Every application is a bit different, but it's not that the PostgreSQL design is a loser in all regards. It's not like bubble sort.

replies(4): >>41897732 #>>41902493 #>>41904079 #>>41905601 #
indulona ◴[20 Oct 24 19:09 UTC] No.41897732[source]▶
> but it's not that the PostgreSQL design is a loser in all regards

the article literally says that pg's mvcc design is from the 90s and no one does it like that any more. that is technology that is outdated by over 30 years. i'd say it does not make it a loser in all regards, but in the most important aspects.

replies(4): >>41898162 #>>41898235 #>>41898303 #>>41902986 #
kunley ◴[20 Oct 24 20:43 UTC] No.41898303[source]▶
Still I am very happy to use every day the technology designed in early 70s by Ken Thompson and colleagues, so far in that specific field many tried to invent something more "modern" and "better" and failed, with an exception of a certain Finnish clone of that tech, also started in 80s by the way.

So, newer not always means better, just saying

replies(3): >>41899219 #>>41899463 #>>41907434 #
1. nine_k ◴[20 Oct 24 23:05 UTC] No.41899219[source]▶
Speaking of which, if you try an actual System V in an emulator, or look at C code in K&R style, certain progress, as in "much more actually usable", can be noticed.

While persisting key architectural ideas certainly has benefits, so does evolving their implementations.

replies(1): >>41918627 #
2. kunley ◴[22 Oct 24 20:58 UTC] No.41918627[source]▶
Yes I agree that implementations must evolve. Still, there are cases where old architectures are just brilliant.

Having said that, I need to add, I am not an expert to say MVCC is good enough to be considered equally good like other write-concurrency mechanism in SQL databases. My example was given to just have a caution when judging, especially that the original counterexample had mentioned notoriously bad architectures (hello, MySQL...)