Most active commenters

    ←back to thread

    366 points virtualwhys | 17 comments | | HN request time: 0.21s | source | bottom
    1. fweimer ◴[] 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 #
    2. indulona ◴[] 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 #
    3. naranha ◴[] No.41898162[source]
    At least couchdb is also append only with vacuum. So it's maybe not completely outdated.
    replies(1): >>41898658 #
    4. mikeocool ◴[] 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 #
    5. kunley ◴[] 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 #
    6. mannyv ◴[] No.41898511{3}[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 #
    7. jbellis ◴[] No.41898658{3}[source]
    High performance has never been a reason to use couchdb.
    8. nine_k ◴[] No.41899219{3}[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.

    9. throwawayie6 ◴[] No.41899463{3}[source]
    > exception of a certain Finnish clone of that tech

    Are you referring to C++? That was actually created by a Danish guy, who was also inspired by the object oriented Simula language created in the 60s

    replies(1): >>41899553 #
    10. nneonneo ◴[] No.41899553{4}[source]
    Pretty sure the OP was referring to UNIX and its “Finnish clone” Linux.
    11. j16sdiz ◴[] No.41902986[source]
    > the article literally says that pg's mvcc design is from the 90s and...

    Actually, it is 1980s. The article:

    > Its design is a relic of the 1980s and before the proliferation of log-structured system patterns from the 1990s.

    12. winternewt ◴[] No.41904079[source]
    > 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.

    When doing game development in the early 2000s I learned that bubble sort is not a loser in all regards. It performs well when a list is usually almost sorted. One situation when this is the case is in 3D rendering, which sorts objects by their distance from the camera. As you move the camera around or rotate it, bubble sort works very well for re-sorting the objects given the order they had in the previous frame.

    To prevent bad worst-case scenarios you can count the number of comparisons that failed on the last pass and the number of passes you have performed so far, then switch to a different sort algorithm after reaching a threshold.

    replies(1): >>41909394 #
    13. 15155 ◴[] No.41905601[source]
    > It's not like bubble sort.

    Bubble sort is great in hardware and for mostly-sorted sets.

    14. gregw2 ◴[] No.41907434{3}[source]
    Err, Linux is a child of the 90s...

    Linus began work on it in April 1991: https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/_R...

    15. simne ◴[] No.41908322{3}[source]
    Tell this to developers of Ariane 5, who used old proven software from Ariane 4.

    Many people consider this most expensive bug in history, when on first flight of Ariane 5, it enters speed range, which was hard prohibited in Ariane 4 software and caused software exception and then 1 billion crashed.

    Honesty, they could re-check all ranges, but they decided, it would cost like write new software, so to save money, was made decision to just use old software, without additional checks.

    16. diroussel ◴[] No.41908961{4}[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
    17. jeltz ◴[] No.41909394[source]
    But wouldn't insertion sort be better than bubble sort in those cases?