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

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

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

    PostgreSQL 16 released today as a very exciting update for this popular open-source SQL server...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.
    Last edited by vegabook; 14 September 2023, 07:33 PM.

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                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

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X