I joined Lemmy back in 2020 and have been using it as [email protected] until somewhere in 2023 when I switched to lemmy.world. I’m interested in systemd/Linux, FOSS, and Selfhosting.

  • 59 Posts
  • 786 Comments
Joined 2 years ago
cake
Cake day: June 10th, 2023

help-circle

  • qaz@lemmy.worldtoProgrammer Humor@programming.devGood Morning
    link
    fedilink
    English
    arrow-up
    10
    ·
    edit-2
    20 hours ago

    I’ve been using ClickHouse too and it’s significantly faster than Postgres for certain analytical workloads. I benchmarked it and while Postgres took 47 seconds, ClickHouse finished within 700ms when performing a query on the OpenFoodFacts dataset (~9GB). Interestingly enough TimescaleDB (Postgres extension) took 6 seconds.

    Insertion Query speed
    Clickhouse 23.65 MB/s ≈650ms
    TimescaleDB 12.79 MB/s ≈6s
    Postgres - ≈47s
    SQLite 45.77 MB/s1 ≈22s
    DuckDB 8.27 MB/s1 crashed

    All actions were performed through Datagrip

    1 Insertion speed is influenced by reduced networking overhead due to the databases being in-process.

    Updates and deletes don’t work as well and not being able to perform an upsert can be quite annoying. However, I found the ReplacingMergeTree and AggregatingMergeTree table engines to be good replacements so far.

    Also there’s [email protected]














  • …definitely takes some getting used to when you come from a non-memory safe language…

    I actually think it’s more like the opposite. The compiler takes the normal rules you apply to avoid issues with a non-memory safe language like C/C++ and enforces them explicitly where memory safe languages don’t have those rules at all. I think lifetimes are much more confusing if you’ve never dealt with a user after free and usually let GC deal with it.

    Also yes the compiler warnings and errors are amazing, the difference between rustc and gcc is night and day.