Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jabberwocky
    replied
    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: https://www.hydra.so/blog-posts/hydr...ally-available

    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.

    Leave a comment:


  • NobodyXu
    replied
    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.

    Leave a comment:


  • flanier
    replied
    I've used Timescale for a couple of years and am very happy with it. There are people working on an updated storage engine for Postgres. How likely it is that that this or any other column store engine would ever be pulled in by the Postgres core team, I don't know.

    Leave a comment:


  • archkde
    replied
    Originally posted by NobodyXu View Post

    That's probably true considering how many legacy code that resides in Linux kernel and how many hardware bug workaround, and how much code that "JUST WORK"s.

    Also, recently Kent tried to push Bcachefs into mainline without obeying the code review process, and skip the linux-next which performs CI testing.
    His code can't even compile on Linus's machine.

    It's absurd how that could happen and how many people still defending Kent's behavior, they claim that since he has been working on Bcachefs for 15 years and is a smart guy, the Linux kernel should loosen the requirement for his patch to merge, which is absolutely absurd for me.
    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.

    Leave a comment:


  • mcloud
    replied
    Originally posted by vegabook View Post
    We need a first-party column store engine for Postgres so that we can do away with third party open"ish" citus and timescaledb. That's the only missing piece in what is otherwise one of the best pieces of open source technology ever created, and brilliantly, rock solidly maintained, consistently pushed forward, and to whom we owe so much. It's right up there with Linux itself.
    I think being extensions allow more than one to exists and also make it easier to improve or make better ones long term. Many stuff taken for granted in postgresql are also extensions. Maybe making it easier and making the extensions run faster would be a better goal. I for one would like the core team to fix real limitations, like the 32 bit transaction ids, even if for new major database version

    Leave a comment:


  • uid313
    replied
    Probably the best database in existence.
    Too bad the user space is messy with tons of different commands instead of everything collected under one command as is done by the "git" command.
    Also too bad it uses their own vanity license instead of something more common.

    Leave a comment:


  • NobodyXu
    replied
    Originally posted by archkde View Post
    Don't forget the other great database engine here, SQLite. I'd even say that both PostgreSQL and SQLite are more rock-solid than Linux due to their more systematic focus on correctness.
    That's probably true considering how many legacy code that resides in Linux kernel and how many hardware bug workaround, and how much code that "JUST WORK"s.

    Also, recently Kent tried to push Bcachefs into mainline without obeying the code review process, and skip the linux-next which performs CI testing.
    His code can't even compile on Linus's machine.

    It's absurd how that could happen and how many people still defending Kent's behavior, they claim that since he has been working on Bcachefs for 15 years and is a smart guy, the Linux kernel should loosen the requirement for his patch to merge, which is absolutely absurd for me.

    Leave a comment:


  • archkde
    replied
    Originally posted by vegabook View Post
    … one of the best pieces of open source technology ever created, and brilliantly, rock solidly maintained, consistently pushed forward, and to whom we owe so much. It's right up there with Linux itself.
    Don't forget the other great database engine here, SQLite. I'd even say that both PostgreSQL and SQLite are more rock-solid than Linux due to their more systematic focus on correctness.

    Leave a comment:


  • stormcrow
    replied
    Originally posted by yoshi314 View Post

    i bet the developers of postgresql mutter something about patches and sending them.
    Or at the very least open a feature request conversation in Postgres' community mailing list.

    Leave a comment:


  • yoshi314
    replied
    Originally posted by vegabook View Post
    We need a first-party column store engine for Postgres so that we can do away with third party open"ish" citus and timescaledb. That's the only missing piece in what is otherwise one of the best pieces of open source technology ever created, and brilliantly, rock solidly maintained, consistently pushed forward, and to whom we owe so much. It's right up there with Linux itself.
    i bet the developers of postgresql mutter something about patches and sending them.

    Leave a comment:

Working...
X