5 ms·

PostgreSQL 18 Released

142 points by jkatz05 1y ago

mattashii 1y ago
Those are some great features. More than I remembered, and it's only been a year. Personally, I'm very happy to see parallel builds for GIN indexes get released - (re)index time for those indexes is always a pain. I'm looking forward to further improvements on that front, as there are still some relatively low-hanging fruits that could improve build times even more.
sudarshnachakra 1y ago
Does this release have the TAM (Table Access Methods) patch set from orioledb? Or at least parts of it?
- mattashii 1y ago
  Doesn't look like it, no. At least not to the degree that it has updated the table AM interface.
- deleted 1y ago
  [deleted]
- jeltz 1y ago
  I don't think so. What do you need it for if I may ask? If some people actually need a patch it is much more likely to get people working on it to make it committable.
  - ksec 1y ago
    TAM is prerequisite for OrioleDB. And I am guessing OP like me is looking forward to orioledb being used as default or even upstreamed.
    - jeltz 1y ago
      OrioleDB is very far from being usable as default or upstreamed. Nobody is working on this right now.
      - kiwicopple 1y ago
        fwiw, we have a team working on OrioleDB at supabase, with the plan to get to GA later this year or early next year. we'll continue to submit patches upstream for the TAM, and of course that will take as long as it takes for the community to accept them. Our focus right now reliability and compatibility, so that the community can gain confidence in the implementation
  - sudarshnachakra 1y ago
    I was wondering how far away OrioleDB was from becoming a pure extension instead of being a postgres fork. I'm not an expert by any means on TAM - but was curious if the Orioledb team managed to upstream some parts of their fork.
    - pella 1y ago
      imho: not soon. Most alternative PG storage engines have stumbled, and OrioleDB touches a lot of core surfaces. The sensible order is: first make OrioleDB rock-solid and bug-free; ( https://github.com/orioledb/orioledb/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug https://github.com/orioledb/orioledb/issues?q=is%3Aissue%20s... ) then, using real-world feedback and perf data, refactor and carve out patches that are upstream-ready. That’s a big lift for both the OrioleDB team and core PG. From what I understand, they’re aiming for a release candidate in the next ~6 months; meaningful upstreaming would come after that. In other words: make it work --> validate the plan --> upstream the final patches.
ktosobcy 1y ago
Eh... interesting features, yet docker upgrade is still huge PITA because upgrade between major versions is not supported :/ I love PostgreSQL, but this is just utterly annoying and discouraging to use it…
- jeltz 1y ago
  That is mostly an issue with the official docker image, not a PostgreSQL issue. Upgrading to a new major is easy if you use the Debian packages and is fine with a couple of minutes downtime. There is no reason a docker image could not do the same. The issue with PostgreSQL which the Debian packages handle fine but the Docker Hub's image does not is that you need both the executables for the old and the new major version of PostgreSQL when upgrading. This just works with Debian packages but not with the Docker image.
  - ktosobcy 1y ago
    I'm fully aware why it's an issue with official image. But even with debian (or any other "packaging") there are hoops to be hopped through due to said missing upgrade handling which IMHO is very annoying. They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade. I (well, a lot of people judging from votes and comments in https://github.com/docker-library/postgres/issues/37 https://github.com/docker-library/postgres/issues/37 and stars in https://github.com/tianon/docker-postgres-upgrade https://github.com/tianon/docker-postgres-upgrade) would love that, and only between subsequent version would be more than enough…
    - mattashii 1y ago
      > They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade Minor versions of PostgreSQL have constraints that major versions don't have; in that minor versions in principle don't see new features added. This allows minor versions of the same major release to run against the same data directory without modifications. However. Major versions add those new features, at the cost of changes to internals that show up in things like catalog layout. This causes changes in how on-disk data is interpreted, and thus this is incompatible, and unlike minor releases this requires specialized upgrade handling.
bo0tzz 1y ago
A quiet addition here that I'm very excited about is the extension_control_path configuration, which will make adding extensions in environments like Kubernetes a whole lot nicer (see eg https://cloudnative-pg.io/documentation/1.27/imagevolume_extensions/ https://cloudnative-pg.io/documentation/1.27/imagevolume_ext...).
tudorg 1y ago
Lots of good improvements, my favorites are Oauth, NOT NULL constraint with NOT VALID, uuidv7, RETURNING contains old/new. And I think the async IO will bring performance benefits, although maybe not so much immediately.
- sergeyprokhoren 1y ago
  PostgreSQL Gains a Built-in UUIDv7 Generation Function for Primary Keys (many interesting details) https://habr.com/en/news/950340/ https://habr.com/en/news/950340/

142 points by jkatz05 1y ago

Those are some great features. More than I remembered, and it's only been a year. Personally, I'm very happy to see parallel builds for GIN indexes get released - (re)index time for those indexes is always a pain. I'm looking forward to further improvements on that front, as there are still some relatively low-hanging fruits that could improve build times even more.

sudarshnachakra 1y ago

Does this release have the TAM (Table Access Methods) patch set from orioledb? Or at least parts of it?

mattashii 1y ago
Doesn't look like it, no. At least not to the degree that it has updated the table AM interface.
deleted 1y ago
[deleted]
jeltz 1y ago
I don't think so. What do you need it for if I may ask? If some people actually need a patch it is much more likely to get people working on it to make it committable.
- ksec 1y ago
  TAM is prerequisite for OrioleDB. And I am guessing OP like me is looking forward to orioledb being used as default or even upstreamed.
  - jeltz 1y ago
    OrioleDB is very far from being usable as default or upstreamed. Nobody is working on this right now.
    - kiwicopple 1y ago
      fwiw, we have a team working on OrioleDB at supabase, with the plan to get to GA later this year or early next year. we'll continue to submit patches upstream for the TAM, and of course that will take as long as it takes for the community to accept them. Our focus right now reliability and compatibility, so that the community can gain confidence in the implementation
- sudarshnachakra 1y ago
  I was wondering how far away OrioleDB was from becoming a pure extension instead of being a postgres fork. I'm not an expert by any means on TAM - but was curious if the Orioledb team managed to upstream some parts of their fork.
  - pella 1y ago
    imho: not soon. Most alternative PG storage engines have stumbled, and OrioleDB touches a lot of core surfaces. The sensible order is: first make OrioleDB rock-solid and bug-free; ( https://github.com/orioledb/orioledb/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug https://github.com/orioledb/orioledb/issues?q=is%3Aissue%20s... ) then, using real-world feedback and perf data, refactor and carve out patches that are upstream-ready. That’s a big lift for both the OrioleDB team and core PG. From what I understand, they’re aiming for a release candidate in the next ~6 months; meaningful upstreaming would come after that. In other words: make it work --> validate the plan --> upstream the final patches.

ktosobcy 1y ago

Eh... interesting features, yet docker upgrade is still huge PITA because upgrade between major versions is not supported :/ I love PostgreSQL, but this is just utterly annoying and discouraging to use it…

jeltz 1y ago
That is mostly an issue with the official docker image, not a PostgreSQL issue. Upgrading to a new major is easy if you use the Debian packages and is fine with a couple of minutes downtime. There is no reason a docker image could not do the same. The issue with PostgreSQL which the Debian packages handle fine but the Docker Hub's image does not is that you need both the executables for the old and the new major version of PostgreSQL when upgrading. This just works with Debian packages but not with the Docker image.
- ktosobcy 1y ago
  I'm fully aware why it's an issue with official image. But even with debian (or any other "packaging") there are hoops to be hopped through due to said missing upgrade handling which IMHO is very annoying. They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade. I (well, a lot of people judging from votes and comments in https://github.com/docker-library/postgres/issues/37 https://github.com/docker-library/postgres/issues/37 and stars in https://github.com/tianon/docker-postgres-upgrade https://github.com/tianon/docker-postgres-upgrade) would love that, and only between subsequent version would be more than enough…
  - mattashii 1y ago
    > They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade Minor versions of PostgreSQL have constraints that major versions don't have; in that minor versions in principle don't see new features added. This allows minor versions of the same major release to run against the same data directory without modifications. However. Major versions add those new features, at the cost of changes to internals that show up in things like catalog layout. This causes changes in how on-disk data is interpreted, and thus this is incompatible, and unlike minor releases this requires specialized upgrade handling.

bo0tzz 1y ago

A quiet addition here that I'm very excited about is the extension_control_path configuration, which will make adding extensions in environments like Kubernetes a whole lot nicer (see eg https://cloudnative-pg.io/documentation/1.27/imagevolume_extensions/ https://cloudnative-pg.io/documentation/1.27/imagevolume_ext...).

tudorg 1y ago

Lots of good improvements, my favorites are Oauth, NOT NULL constraint with NOT VALID, uuidv7, RETURNING contains old/new. And I think the async IO will bring performance benefits, although maybe not so much immediately.

sergeyprokhoren 1y ago
PostgreSQL Gains a Built-in UUIDv7 Generation Function for Primary Keys (many interesting details) https://habr.com/en/news/950340/ https://habr.com/en/news/950340/