←back to thread

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

(www.cs.cmu.edu)
366 points virtualwhys | 2 comments | 20 Oct 24 15:30 UTC | HN request time: 0s | 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 #
mikeocool ◴[20 Oct 24 20:29 UTC] No.41898235[source]▶
When it comes to your data store, some people might consider using technology that’s been reliably used in production by many organizations for 30 years a feature not a bug.

I’d prefer not to be the first person running up against a limit or discovering a bug in my DB software.

replies(2): >>41898511 #>>41908322 #
1. mannyv ◴[20 Oct 24 21:12 UTC] No.41898511[source]▶
Well every product has issues. The question is, do you feel like dealing with those issues or not?

Flat files have also been reliably used in production for decades. That doesn't mean they're ideal...although amusingly enough s3 and its equivalent of flat files is what we've migrated to as a data store.

replies(1): >>41908961 #
2. diroussel ◴[21 Oct 24 21:59 UTC] No.41908961[source]▶
It would be quite nice to have some of the S3 semantics on local files. Like no one else can the see the file until after you’ve finished writing the file and committed it. And being able to put almost any chara in the file name (key). That is quite nice in S3