Postgres FM - Postgres 17

Episode Date: September 27, 2024

Nikolay and Michael discuss the fresh new Postgres 17 release! They cover several performance improvements, favourite new features, and some considerations for upgrading. Here are some links to things they mentioned:Postgres 17 release notes https://www.postgresql.org/docs/17/release-17.htmltransaction_timeout episode https://postgres.fm/episodes/transaction_timeoutVACUUM improvements discussed towards end of episode with Melanie Plageman https://postgres.fm/episodes/getting-started-with-benchmarkingB-tree improvements discussed in episdode with Peter Geoghegan https://postgres.fm/episodes/skip-scanAs Rails developers, why we are excited about PostgreSQL 17 (blog post by Benoit Tigeot) https://benoittgt.github.io/blog/postgres_17_rails/ Real World Performance Gains With Postgres 17 B-tree Bulk Scans (blog post by Brandur Leach) https://www.crunchydata.com/blog/real-world-performance-gains-with-postgres-17-btree-bulk-scansMERGE RETURNING came up towards end of episode with Haki Benita https://postgres.fm/episodes/get-or-createuuid_extract_timestamp and uuid_extract_version functions https://www.postgresql.org/docs/current/functions-uuid.htmlEpisode on UUID https://postgres.fm/episodes/uuidPartitioning by ULID https://postgres.fm/episodes/partitioning-by-ulidWhy Upgrade? (site by depesz) https://why-upgrade.depesz.comWhy we spent the last month eliminating PostgreSQL subtransactions (GitLab blog post) https://about.gitlab.com/blog/2021/09/29/why-we-spent-the-last-month-eliminating-postgresql-subtransactionsSynchronization of sequences to subscriber (patch that needs review!)  https://commitfest.postgresql.org/49/5111~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith special thanks to:Jessie Draws for the elephant artwork 

Hello, hello, this is PostgresFM, and today, as usual, only two of us, not as usual, sometimes we have guests, right? So, my name is Nikolai, PostgresAI, and my co-host is Michael, PidgeyMastat, hi Michael. Hello, Nikolai. Yeah, how are you doing? I am good, how are you? I'm very good. So we decided, you decided actually, I probably wouldn't decide myself, but you decided suddenly, and this is a coincidence, I guess. Hopefully yesterday Postgres 17 was released.

So let's talk about some features, random features we just picked up from the list. It has a lot of, a long list of features, right? As usual. Yeah, absolutely. Hundreds. So we're definitely not going to be able to talk about the vast majority of them. So it'd be good to hear, like,

looking through the list, which are your favorites. But before that, I think it's worth saying it's actually really impressive. A group of distributed people shipping to a release date that they've set quite a little while in advance you know they've had several beaters a release candidate a few weeks ago and barring i haven't seen any big issues so i'd be surprised if it isn't but completely respect the people making the final decision if they have decided to postpone

but yeah it's really impressive that they can ship to a date that and each year we get a new major release i think that's not super common in large distributed projects to get major releases annually same time every year almost you could set your set your calendar by it yeah it sounds like obligation which usually is happening inside big corporations right like let's plan to do this and be consistent yeah and i know there's a lot of infrastructure or like kind of things like the commit fests that mean you know there's a feature freeze many many months in advance and that's the kind of thing that allows them to be predictable. Like if they allowed features to go in nearer the end, that would almost certainly postpone things if something went wrong.

It means there's tons of time to revert things if needed. There were a couple of things reverted again this time. Well, one of the most popular Linux distributions is doing a similar thing, right? Which one? Ubuntu. Releases are like this structure defined long ago and every year

two releases, right? And there are long-term support releases as well and this is similar to Postgres has. Yeah, good point. Yeah, we don't have, almost every version is LTS, I feel like, in Postgres has. Yeah, good point. Postgres doesn't have LTS, but... Yeah, we don't have... Almost every version is LTS, I feel like, in Postgres. Like, it's supported for

five years. Postgres doesn't have this concept, but my point is that it's also like planned dates of releases, right? Same thing. Yeah, true. Another good example. And also quite popular project. Yeah, I've heard of it.

Also open source. Yeah. Right, but there is a single company behind it. Yeah, true. Yeah, well, okay. I also wanted to mention that those who listen to us regularly should already remember some features coming with this release. We discussed a few of them in recently in

previous episodes transaction timeout so this whole episode what else yeah improvements yeah vacuum improvements came up when we had a good conversation with melanie and we talked to peter gagan recently yeah about and that was that work is split over 17 and 18. But even since we spoke to Peter, there have been some cool blog posts about those improvements and people benchmarking them against real workloads. And the results are pretty cool. So both Benoit, who we mentioned in the episode,

has published a blog post that I'll link up, and the Crunchy Data team, i think it was brander published a great blog post benchmarking those improvements i believe it's almost entirely due to those improvements so yeah that was really cool and i think there's one more as well yes we discussed with haki benita get or create in which the topic of merge returning came up which we're getting in 17 so yeah for at least four of the of the several hundred features we've discussed i also like maybe this will be a start already i wanted to thank to congratulate basically andrej borodin who has multiple contributions in this release and two of them were started during Postgres TV online hacking sessions. It's transaction timeout and also UUID version 7 functions.

Unfortunately, Postgres 17 doesn't have UUID version 7 because there was decision to wait until finalization of RFC, So standard needs to be out. Actually, it also was a controversial decision because many libraries already implemented UID version 7. A lot of them. Not just library, Go library, many, many, many. Relying on the fact that it's very unlikely that something will change.

But Postgres decided to be more conservative. And, well, it's very unlikely that something will change. But Postgres decided to be more conservative and well, it's okay. But Postgres 17 has a function uuid.extract.timestamp. So we can like it's a preparation basically. And also uuid.extract.version to return uuid information. And I remember also the decision to have this function also was controversial. The authors of Standard didn't encourage the fact that we can extract timestamp from UUID version 7. It's interesting, right? UUID version 7 is not supported,

but already there are functions which are prepared to work with it. And they are not part of Standard. Maybe that's why they are really being released right but to me this is an interesting feature because i think it's already so we for our clients during consulting sessions when we see uid version 4 being used as primary key we say don't do it because there are many articles already showing with benchmarks showing how bad it is to have uh for for b3 health it's bad to insert in the arbitrary places insert yeah

basically randomly right and uid version 7 it has benefits from both worlds actually i think we had episode about i think we did yeah maybe, maybe I was alone, actually. Yeah, so we encourage to use UID version 7. And it's interesting that it's easy to move from UID version 4 to version 7 in an existing project. If you have a big table already, you just... They have the same similar format, right?

So you don't need to change anything besides how default is organized or how you insert value itself so no table structure changes which is good and yeah i think this fact that now we have a function which allows us to extract timestamp if it's version 7 which has timestamp it means also probably in many cases we can avoid additional 16 bytes for column created at because we can get this information right from the ID column.

And also we can work with this information to have time-based partitioning. Even TimescaleDB can work with this. I have a recipe somewhere. I think we also discussed this. That's the one I joined you for, partitioning. Even timescale DB can work with this. I have a recipe somewhere. I think we also discussed this. That's the one I joined you for, partitioning. Okay, so we had two episodes about UID version 7 and how to partition with it. I think it's very basic, important tricks to know about because it can be useful in many, many systems.

So this function now is part of core of Postgres, so just use it. It's great. What else? What else do you want to discuss? Well, maybe as a starting point, do you have a favorite or favorite kind of theme or area of improvement in 17?

Well, my overall impression, like I had this in many previous Postgres versions when they were released, impression is a lot of small stuff, but sometimes it's very important stuff for some projects. There's no like huge, one big huge thing in this release, right? And of course I like transaction time out because it was my idea i like it a lot right so and i like i'm very grateful to andrei who implemented this online

and i like that we have it now i have further idea we started discussing let me share it so i was thinking a log min duration statement setting defines when it's similar to timeout basically, but instead of cancelling your transaction issue in rollback, right? It just logs. So you're thinking log min duration transaction? I think about transaction, I think about idle and transaction state as well. Instead of canceling, we could just log and maybe draw some, like let's not cancel, but warn, right, that something is not good here happening.

Basically, each transaction consists of only three normal states. Either we execute some statement or we don't execute something, right? We are idle between two statements or between statement and commit, for example. So what's the third? Third is the hole. What do you mean?

Oh, sorry. Two states, but also there's a hole. Sorry, sorry. Okay, I understand. So either we do something or we don't do anything inside transaction. There is also state outside, which is idle, right? And there's a hole. So basically three timeout settings make sense. This already finally fully implemented in 2024. But also it would make sense to warn just logging, right?

Maybe it's a good idea as well, right? I think so. I think I just came uh this this idea came to me like a few days ago honestly maybe i should write to hackers about this so you mean like as somebody as an administrator or somebody looking after this database i can start to think we could be in trouble here if we let this get out of hand instead of instead of punishing the users or whoever is actually in the middle of a long transaction, we could proactively go about, can we optimize those things?

What are they doing? Before they cause us problems, instead of kicking them out, we could. Yeah, well, I see sometimes people hesitate. Like we usually in OTP, we recommend very low values for all timeouts because my usual approach is why http server has like 30 second timeout or 60 second but on database which is like even more dangerous to to do something very long when people already don't need it why don't you limit it right so we advise to limit very aggressively but sometimes people hesitate or what happens so logging would be first thing right cool i get it so like selling

it into as a change it's easier to encourage people to start logging those yeah yeah yeah of course uh naming will be hard as usual because I don't session transaction timeout, I remember. Yeah, this was one of the longest, maybe the longest name. And this also triggered my thoughts. It's slightly off topic, but let me share it quickly. I think log timeout is named very wrong. Very wrong. Because it's not log timeout.

It's log acquisition timeout. It doesn't define duration of waiting for lock being held. Because once lock is acquired, this timeout is not in effect anymore, right? So it should be lock acquisition timeout. Do we want lock timeout? Maybe no lock timeout. Maybe we want lock timeout? Or waiting on lock, yeah. Maybe no lock timeout. Maybe lock timeout would be needed additionally. So it's an interesting area when you try to think about systematically.

Yeah, like there are not implemented areas also and naming things and so on. But it's interesting. Anyway, I not consider this as negative feedback. I'm just thinking how to improve. And maybe we will come up with new proposals and patches and so on. By the way, I think I agree on your overall sentiment that there's no one huge feature in PostgreSQL 17. There are some big ones.

Like, I think incremental backup was a lot of work. But it's not necessarily it's not like when we when we got parallel query or when we first got declarative partitioning i guess there's no kind of headline feature but there's a couple of themes i thought from the from the release notes one i think is in mostgres releases, but there's a lot of performance improvements. Maybe small, but some maybe large, like we talked to Peter about and like have been benchmarked for some workloads. Those could be large improvements. But it's not just that one.

There's quite a lot of performance, like individual commits and features around performance. Again, not for the first time. And another theme is there seem to be quite a lot of improvements around logical replication. Agreed as well. Yeah. And it continues to be so. In 16, we had also a lot

of improvements in this area. Anything particularly you want to discuss in these two areas? So performance, I'm going to point people towards the blog posts. I think the CrunchData one in particular is brilliant. And basically the summary of that is for certain, I think largely, I think that might be a Rails application.

If not, I think it's an ORM-based one. I need to check but for certain workloads even the preliminary work that peter gagans and matthias vandermint have done obviously peter said it could be any amount but it could even be 20 to 30 percent on some workloads globally like across the whole workload i know individual queries queries could be no faster or thousands of times faster depending on the individual cases. But those kind of numbers, 20-30% on a real endpoint

is massive. You don't need to do anything. As a reminder, other than upgrading Postgres, you don't need to change your code and you get that improvement. It's quite remarkable, I think. Yeah, there are optimizations in the area of aggregate functions and also parallel processing, right?

And not to forget optimizations in the vacuum. Multiple optimizations from Melanie, right? Yes. So, yes, on top of the work that we discussed with Peter around in- list optimizations basically the starts of the skip scan work yeah we've got vacuum should be more efficient not just through the work melanie did but a bunch of other ones i think analyze as well can now use like some defaults have been changed there's one that's uh being bumped from 256 kilobytes to two megabytes

on the shared buffer ring that can be used for vacuum and analyze so in a bunch of cases they'll run faster without you having to change anything for huge vacuums i think i think was it um the what melanie did should really help with huge tables so yeah there's there's tons of improvements around that stuff at the parallelism one i saw tom lane made a change that should allow more types of operation to run in parallel which is pretty cool yeah so yeah i'm not sure obviously it's going to depend on individual workloads it'd be great to hear some real world stories of people that do test these upgrade and those are always really helpful and encourage others to upgrade as well we already started talking to our ai assistant like let's

let's benchmark something and uh like i maybe should start this work earlier but maybe like now we will find some examples yeah i think we will maybe start from analysis of mailing lists and find some interesting examples. But if there are real workload scenarios, it's also interesting if I'm hunting for this, honestly, like what example could demonstrate the benefits from 17. So we could reproduce it in synthetic environment. It's always tricky, actually, when you have a life system, how to extract a piece of it and then have fake data and so on. It's like always tricky. Yeah, but I think something in the area of vacuuming definitely should be analyzed. And for example, I remember one of optimizations was how vacuuming of tables without indexes is done.

But I doubt I will see, if I see some table without index in production, I will raise questions, of course. But this is one of the things to check, maybe. It must be rare to have tables without indexes, but I imagine that people have done that extremely deliberately. Anybody that does have a table without indexes, that means there's no primary key.

There's so many... Yeah, no logic. What? Yeah. If you don't use replica identity full, which is not good sometimes and so on. So you mentioned some settings, and I must return to Andrei Baradin

and another his contribution, which was, it was under development many years. This is ability to configure the size of various SLRU caches. And I think 2020 to 21, I wrote this article, right? It was related to incidents GitLab had with sub-transactions. And at that time, this patch was, I think, version 13, 14. This patch had many versions. So the ability to increase some caches. And one of the problems we analyzed at that time was not a good problem when on the primary primary we had long transaction

we use sub transactions and suddenly we have we see at some point we see degradation on all standbys because SLRU cache is overflown but I must admit at that time when we like we tested the patch and we tried to understand how the bigger size of SL recache will help. And in some cases it helped, but I might like three years ago already, right? So I don't remember all the details. But as I remember, it was tricky, not like linear effect, you double this and like, you have two more seconds until the problem hits you. So I think this is a good area also to check, but it requires two node setup, you need to do it on replica. That particular problem you need to inspect on replica. Unfortunately, our AI cannot do such experiments yet, I think maybe we should

implement this. But it's not only about sub transaction SLRU, it's also about multi-exact buffers and so on. So it's interesting to see various performance cliffs and how we can mitigate them now in Postgres 17, because if we have some production incident related to multi-exact IDs and SLRU buffer overflown, we can just increase it, right? At least to postpone this, to shift this cliff and think how to improve and avoid it completely. Yeah, it's really cool. I see that reading the release notes, I see that it comes with seven new parameters. But crucially, and I think this is really important, I see that reading the release notes, I see that it comes with seven new parameters. Yeah.

But crucially, and I think this is really important, three of those scale up automatically with shared buffers. Yeah, that's really cool. But that means I think fewer people will run into this in the first place. Because we have to tune shared buffers, and all cloud providers do by default, that means that these are going to be increased by default as well, which is really cool.

Yeah, I wanted to check YUpgrade by Depeche, which also provides the list of configuration changes, but unfortunately it doesn't support 17 yet. Well, bear in when we're recording a few days ago so there's a very good chance that uh depeche is great at new version support that's a i always use that tool and that website and suggest our clients to to use it so it's very helpful indeed yeah yeah so what else what else do you want to discuss in this release? Well, I've got a couple of things. In fact, we didn't really talk that much about logical replication.

There's a bunch of changes. And I feel like probably the most important is that logical slots will now still exist after failover. Yeah, that's great. In 16, it was already possible to use logical slots on physical standbys. Yeah, that's great. In 16, it was already possible to use logical slots on physical standbys. Yeah. But if failover happens or switchover, actually, it doesn't matter if it's planned or not.

The biggest problem with logical replication, you always lose it. You lose logical replication if failover happens or switchover. And this means that you need to start from scratch with initialization it's nightmare. And of course, recipes existed to solve this, but they were not official. For example, Patroni supported it for a couple of years already. And then Patroni this problem

was solved. But now it's solved in core in 17. So if I lower, it's not a headache anymore. But I must admit, logical is tricky. There are many issues. And not obvious issues sometimes. As I remember, the problem with restarts is not yet solved. The problem with duplicates. During restart, you might see same changes coming in cdc stream again

and if on the subscriber you don't have a unique key nobody can check them and you have you end up having duplicates i think this problem is not it's not it's maybe very hard problem to solve because a slot position lsn position may be lagging a little bit and during restart you might be losing i might be mistaken but i remember some practical problems within this area well and we were talking just before the call like there are still the the major limitations that that are worth remembering are that sequences aren't synchronized and DDL, of course. But I can imagine, let's say, in a few versions' time, if each of those gradually get ticked off, we're going to...

Because there is work in progress. Yeah. I can have it for quite some time, and I hope... For example, a sequence, I just checked it. The patch for sequence replication and logical replication it is waiting for review so let's advertise it if someone wants to help this is good point and people need it one of the biggest concerns with logical is lack of replication of sequences DDL and the third one was fell over but finally

17 solves it but we had some like five minutes of preparation before the show and you mentioned that this feature ah no there is one more sorry upgrades right you mentioned about upgrades so yeah so slot is not lost so it is not lost when you upgrade. This is another big thing, because usually if we upgrade, perform major upgrade on Postgres, again, logical slots are lost. We need to reinitialize it. Again, headache. But now it's supported in 17. And you mentioned very correctly that it's supported only for very distant future because the previous version should be 17. So it will be beneficial only in future upgrades to 18 and so on. Yeah, exactly.

Or from 17, whichever. Yeah. So even... We cannot upgrade from 17 yet anywhere. Exactly. So we cannot use this feature this year, basically, at all. But it makes sense. This is how it had to be implemented.

Right. Unless you backpatch it. Strategic move, right? Yeah. It makes perfect sense, and it means in the future. The world moves remarkably quickly. I remember when Postgres versions came out that are almost out of support now.

Like that's, it takes five years, but that can fly by. So I imagine we'll be using that quite soon. Yeah. Can you imagine? I like, my contribution, XML, not my, like I was a little bit. I know what you mean.

But it was 8.3. Yeah, wow. 2008. So, yeah, I'm already, yeah. And there are people who remember even the beginning. So, yeah, it's interesting how much work is done and consistent work, right? It's great.

But let me criticize a little bit once again i have no idea why pg weight events view uh is called so and this is it's a dictionary this is like just a list of course we need a dictionary because so many weight events right well and crucially i think it allows external providers to add they can now add wait events and name and like give you information about them. So if you're an extension, that's great. But that is really cool. But it's like there is PGLocks, for example, and it's not a list of locks. I see what you mean.

Something isn't with naming, like naming is one of two hardest computer science problems we know. Okay, so that's it. This is my feedback. It's great to have a list,

but maybe I expect some confusions in this area. I think naming is hard even in a project

where you have a benevolent dictator or only a single developer. Naming is already difficult.

Naming in a distributed project when you can't really expect everybody to be aware of, well, I mean, this might be an exception. This might be one that more people could have caught. But I think it's extremely hard in a distributed project. And in this area, another example of issues with naming is there is a wait event called in PG-STAT activity, and it can be null.

And many, many monitoring systems visualize it as a green area. I think it came from Oracle maybe, but RDS does it with performance insights. Pesh viewer does it. This is Java application, which is very useful. If you don't have persistent monitoring and just ad hoc, you can use that as an ad hoc tool. And they say CPU. Yeah, I remember this.

We talked about this, right? CPU. So this very release is confirmation that I'm right. Okay, we have CPU when we see null. But Postgres documentation says null means not waiting. But from time to time, we see new wait event is added. And here we also see it for, I think, checkpoint waiting for checkpoint or something. Yeah, there is something, right?

Custom, yeah, extension to define custom wait events is great. Yes. But if we don't define it, we have null, right? And monitoring systems visualize it as CPU. But also this release adds checkpoint delays. I blame the monitoring systems for that, not post-processing. Yeah, yeah, yeah, of course, of course. I'm just explaining the

problem with naming and it's it's very hard to escape from this problem i recently participated again so let me explain so wait event is now means not waiting according to documentation but it's not fully fair and this is a problem of postgres documentation it should say not waiting or waiting on wait event which not yet defined right or unknown you know like unknown right this is this is now meaning unknown yeah well maybe yeah it's hard but because it's it's about code coverage with like we need to cover more and more code with with wait event analysis which is great like i like i was super skeptical like three four years ago now i think weight of analysis should be in the center of many dashboards so then monitoring systems just make another step in this confusion and say CPU, green area CPU. And when we

sometimes try to find correlation between spikes of CPU usage, and CPU areas in when we also apply segmentation by query ID, we cannot find what's happening. And this release adds new wait events for checkpoint delays by thomas moonro yeah so it means that before 17 it was now right and in monitoring it was cpu and there's big confusion here so what should be done in documentation probably it should be saying as with as you said like or unknown, right? Or unknown wait event. But in monitoring systems, it should be CPU

or some unknown wait event. Right? But recently I participated in some design of dashboard, and we discussed this, and it's really hard. It's very tempting to pull just three letters, CPU, and that's it.

But at least it should be CPU, like asterisk and some remark somewhere, right? I think so. Well, it depends. I find this is like a really difficult one where you either want to try and simplify things for people. And sometimes it's okay to lose a bit of the truth when you're simplifying things. But in other cases, it really isn't or it's harmful to remove that detail and i think this is one of those cases where it might be harmful but yeah tricky one but it's great that this is extended it's great that we have a dictionary of

all events now and it's also great that there is uh extensions can extend extensions can extend this wait event list additionally. We already saw PgStatsStatements wait event, I think starting in 16 or 15, because before it was also null and CPU, but then you see, oh, it's contention at PgStatsStatements. Remember this episode about 4 million TPS. So yeah, I expect more and more will be covered, but I encourage monitoring system developers

to put at least asterisk and remark. That it's not, CPU may be. We can name it CPU may be, in parentheses. Right? Yeah, I quite like that yeah yeah yeah or probably

yeah but we will just have it it's CPU and it's actually doing some work but maybe it's some wait event

which not yet already not yet defined right so yeah it's interesting interesting many small changes

including in observability related things like I expect monitoring systems will deal with renaming and so on again. And lots of changes there to be fair. And even like to the views, there's like a new view, I think as well. But I think it's mostly columns from a different view, because it didn't make sense for them to live there. So yeah, I wanted to congratulate Andrei Baradin. And also I wanted to congratulate Andrei Baradin and also I wanted to congratulate all checkpoints

which now have their own system view pgstart checkpoints the first to leave information about checkpoints was always in pgstart buffer cache which was ridiculous, unclear I saw many confusions, finally

it's resolved, great was it in BG writer? Oh, BG writer. Sorry, not Bafangash. I was just looking at, yeah, background writer, which is like additional mechanism, but check pointer is the main mechanism, right? But stats for both until 17 was present in BG.

BG stat, BG writer. Now we have two separate system views and no more confusion, which is great. But more work on shoulders of monitoring system developers. Yeah, and I don't envy those folks that are having to update for Postgres 17, but there's definitely some already have done

it like i was checking out pg watch 2 and they look like they've already they've got a branch for i don't know if it's been merged yet um so it's pretty cool to see is that pg watch 3 is being developed and it was renamed to pg watch without numbers oh Well, on their Pidgey Watch 2 repository. Okay, it's not that, but the focus is yeah. It's not bad. Recently, I guess, Paolo Golub renamed it to Pidgey Watch without numbers, so

no more confusion in the future. But as I understand, it's not yet fully released. Maybe what you talk about is in the old Pg watch 2 and we maintain the fork of pg watch with our own dashboards looking forward to merging efforts uniting efforts in the future with main pg watch before you have to add postgres 17 support yourself i don't know honestly i just thankfully with AI, it's faster now.

You say, this is my code, this is changes, like help me to develop the change and so on. Yeah. So it's because it's quite mechanical, this change. Actually, before we move on to support from various others, I actually haven't mentioned my favorite feature. Well, maybe not. I don't think it's the most important feature in Postgres 17 by a long way but i think it might be the one i end up using the most and i don't know

if you saw this but you can now provide parameters to rant the random function and you can do them for example in integers so you could do random 1 comma 100 and you get a random integer between one and 100 yeah but it's just a syntax sugar it's convenience i know i know but i think the amount of times in in example code and writing or even in even in real things you're having to then multiply that by a number and then do like seal or floor or like it's just like a load of cruft that you have to put around something and i think it makes it less clear in like a blog post or something exactly what you're doing there so i really i think i'll end up using that the most yeah also let me let me return us to the area of confusion resolution i remember how i shot several feet of myself in the past using hyphen D originally with P-SQL because it's database, right?

It felt not convenient to specify database without any options. So I got used to using the hyphen D database. And then suddenly I had some nasty situations when with pgbench, if you used hyphen D, something goes very wrong. Because there it means debug. Oh. Yeah. It was interesting, I remember.

So Postgres 17 resolves this. Hyphen D means database in both utilities now. Even in p Bench now. Wow. Yeah, and hyphen hyphen debug is the new option for PG Bench. So one more confusion to be resolved. That's great. Nice.

Yeah. This release is confusion resolution release. Yeah. If we forget about PG wait events. Right? Because, yeah. Okay. Well, it's reduced still.

Balance is positive. I must admit. Yeah, that's great. So, yeah. Awesome. Is there anything that you'd warn people? I like to encourage people to upgrade to the major versions. No. major versions no but mostly because mostly because i see people overall having a little

bit too much reticence to do to do so like they they treat postgres like most projects and are very very cautious on upgrades and often lag several versions behind yeah well i like to push people to of course of course yeah of course it's worth upgrading non-production environments already like basically now but uh on production and on production environments it's worth upgrading when it will be 17.1.2 and if if everyone follows this rule waiting for 17.1 it will be lacking improvements and fixes. So, of course, if you can afford upgrading some less critical clusters, it should be done earlier.

Or if the benefits are worth it. If there's a project that would massively benefit, then those ones might be worth a bit more risk. It happens sometimes. But still, my recommendation for critical, super important clusters, I would wait a little bit, or perform a very thorough testing myself,

I mean myself with my team, and only then upgrade. Because jumping straight to 17.0 in critical production sounds crazy and any SRE or DBRE will admit it this is conflicting recommendation, let's upgrade faster and let's be very

cautious that some bugs might happen because it's just released there should be balance here as well I'll be interested to see what people do. If you do upgrade soon, let us know how it goes. And let the Postgres community know as well. I think there's a lot of people that have worked hard on this. It's always great for them to get that feedback.

Yeah. In our lab environments, we already have 17 and start using it since a few days ago. In all environments, we have 17 supported so we benchmarks and so on already on 17 and it's already something it's not production of course but it's already something if some bugs happen and what's good in our case we in many cases we compare with previous versions so it's super easy with our ai and I hope we will find some problems and report. Yeah, the main read, like, obviously, there's risks, but there's also is well worth checking support from tools you

use, like extensions, often a lot of ones I checked haven't yet. Oh, many already. 17. Yeah, yeah many do but many don't as well um yeah yeah a few days ago i approved mercy quest for db lab engine and we have extensions a lot of extensions and our custom images for postgres and i i saw this like i expected much longer list of unsupported in 17, but it was like five items only. We have dozens of good extensions additionally to contrib modules. Well, some that don't, for example, I didn't see, did you see Timescale or Citus? Timescale was not there, I think. Yeah, it's big.

PG Repack as well, I didn't see. these are these are ones that it doesn't matter to somebody if like most of their extensions are supported if there's one that they're using that is critical and it's not supported then yeah i'm looking at the list and yeah indeed the pg repack pg pg qual stats it's POVA, and the timescale, Cytos, you're right. And again, hopefully in the next few days, a lot of these will change. They could easily be waiting, hopefully as of Thursday, which is yesterday, if you're listening to this on the day it's released. But pgvector is fine.

It's already supporting 17. Yeah, and lots of other tools have already, like, we shipped ProSquare 17 support the other day. Petroni as well, version 17 support already. Like, loads of tools do, which is great. But yeah, I just thought it was worth saying, it's worth

people checking that the tools they rely on do support it already. Good. Okay. Nice. anything else you wanted to say no i think that's it upgrade but carefully yeah or at least check out the release notes and see if there's anything important in there for you right right good thank you michael nice one take care see you soon