No announcement yet.

PostgreSQL 16 Released With More Performance Improvements, SIMD For x86 & Arm

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by archkde View Post

    That's not really what I meant. The bcachefs drama seems to be mostly caused by some process mismatch between Kent and the Linux developers. It's not like some random garbage (which bcachefs likely isn't to begin with) has been merged (it hasn't).

    Better examples for what I mean are the frequently shipped severe regressions (some examples from the top of my head: 5.19: Intel GPU nonsense, 6.3: XFS corruption, nftables verdict map fallthrough, 6.4: userspace stack corruption). You can also see in the bcachefs thread where there is some discussion about XFS, where the fuzzer issues of the old on-disk format are mostly ignored, and the only real fix is to use the new one (which requires a reformat). Half-assed features are shipped all the time (pidfd_getfd is severely limited by pidfd shortcomings, NTFS driver is buggy and mostly abandoned). And while the Linux kernel does have a test suite, it is not nearly as comprehensive as the SQLite one.
    Thanks, I guess Linux kernel just does not have enough maintainers or enough code review.

    I think it's time to adopt move more components into the userspace and then compile all kernel modules into web assemblies and run in sandbox, it would at least prevent UBs/bugs from shutting down the entire kernel.

    I also think that adopting Rust will indeed reduce amount of memory related bugs and makes it easier to review for UB.


    • #12
      I'm assuming this is just an initial SIMD release and that there still would be many improvements in the following years. I found out that there's a lot of PostgreSQL forks and saw Hydra released v1.0 yesterday:

      I'm disappointed that I did not have the opportunity to experience Postgres properly. I've heard many good things about PostgreSQL since Oracle took over MySQL. I've mostly been using noSQL in Telecommunications*, Mining, Agriculture, Education, Fintech** and large scale industrial monitoring for just over a decade.

      * In Telecommunications we used PostgreSQL but that was just for a small part of the system and JSON support was sorely missed at that time. Most of the data was stored in a TSDB.

      ** In some Fintech projects we had psql and mssql support but again just for a small part of the system. We also didn't use any "special features" and we didn't store a lot of data. The majority of data was stored in RocksDB.

      I hope that I'll get a chance to use PostgreSQL properly in the years to come.