Nikolay: Hello, hello, this is PostgresFM and today as usual
only 2 of us.
Not as usual, sometimes we have guests, right?
So my name is Nikolay, Postgres.AI and my co-host is Michael,
pgMustard.
Hi Michael.
Michael: Hello Nikolay.
Nikolay: Yeah, how are you doing?
Michael: I am good, how are you?
Nikolay: 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.
Michael: 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 betas 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
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 calendar by it.
Nikolay: Yeah, it sounds like obligation, which usually is happening
inside big corporations, right?
Like, let's plan to do this and be consistent.
Michael: 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 near 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.
Nikolay: Well, 1 of the most popular Linux distributions is doing
a similar thing, right?
Which 1?
Ubuntu.
Oh.
Releases are like this structure defined long ago and every year
2 releases, right?
And there are long-term support releases as well.
And this is similar to Postgres has.
Michael: Yeah, good point.
Nikolay: Postgres doesn't have LTS, but...
Michael: Yeah, we don't have...
Almost every version's LTS, I feel like, in Postgres.
Like, it's supported for 5 years.
Nikolay: Postgres don't have this concept, but my point is that
it's also like planned dates of releases, right?
Same thing.
Michael: Yeah, true.
Another good example.
Nikolay: And also quite popular project.
Michael: Yeah, I've heard of it.
Nikolay: Also open source.
Yeah.
But there is a single company behind it.
Michael: Yeah, true.
Nikolay: 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 recently in previous episodes.
transaction_timeout was a whole episode.
What else?
Vacuum improvements?
Michael: Yeah, vacuum improvements came up when we had a good
conversation with Melanie.
And we talked to Peter Geoghegan recently.
Yeah, and that work was 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 Brandur, 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 1 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 4 of the of the several hundred features
we've discussed.
Nikolay: I also like maybe this will be a start already I wanted
to congratulate basically Andrey Borodin who has multiple contributions
in this release and 2 of them were started during Postgres TV
online hacking sessions and it's transaction_timeout and also
UUID version 7 functions.
Unfortunately Postgres 17 doesn't have UUID version 7 because
there was a 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 UUID version 7, a lot of them, Node.js 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
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.
I remember also the decision to have this function 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 being released, right?
But to me, this is an interesting feature because I think it's
already so.
For our clients during consulting sessions, when we see UUID
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 — for B-tree health, it's bad
to insert in arbitrary
Michael: places.
Randomly.
Nikolay: Yeah, basically randomly, right?
And UUID version 7, it has benefits from both worlds.
Actually, I think we had an episode about.
Michael: I think we
Nikolay: did.
Yeah, maybe I was alone, actually.
Yeah, so we encourage to use UUID version 7.
And Interesting that it's easy to move from UUID version 4 to
version 7 in existing projects.
If you have a big table already, you just...
They have the similar format, 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.
Michael: That's the 1 I joined you for, partitioning.
Nikolay: Oh, okay, so we had 2 episodes about UUIDv7 and how to
partition with it.
It's very, I think it's very basic, important tricks to know
about.
Yeah.
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?
Michael: Well, maybe as a starting point, do you have a favorite
or favorite kind of theme or area of improvement in 17?
Nikolay: 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, 1 big huge thing in this release, right?
And of course I like transaction_timeout because it was my idea.
I like it a lot.
I'm very grateful to Andrei who implemented this online.
I like that we have it.
Now I have a further idea we started discussing.
Let me share it.
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.
Michael: So you're thinking log min duration transaction?
Nikolay: I think about transaction I think about idle in transaction
state as well.
Instead of cancelling, we could just log and maybe draw some...
Let's not cancel, but warn, right?
That something is not good here happening.
Yeah.
Basically, each transaction consists of only 3 normal states.
Either we execute some statement or we don't execute something,
right?
We are idle between 2 statements or between statement and commit,
for example.
Michael: So what's the third?
Nikolay: Third is the whole
Michael: What do you mean?
Nikolay: Oh, sorry, 2 states of but also there is the
whole. Sorry sorry. Yeah, Yeah, you're right.
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, 3 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 just I think I just came This idea came to me like a few days
ago, honestly Maybe I should write to hackers about this.
Michael: So you mean like 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 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?
Like before they cause us problems, instead of kicking them out,
we could.
Nikolay: Yeah.
Yeah.
Well, I see sometimes people hesitate.
Like we're usually in OLTP, 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 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, oh what happens?
So Logging would be first thing, right?
Michael: Cool, I get it.
So like selling it as a change, it's easier to encourage people
to start logging those.
Nikolay: Yeah, of course naming will be hard as usual because
I don't session, transaction_timeout, I remember.
Yeah, this was 1 of the longest, maybe the longest name.
And this also triggered my thoughts.
It's slightly off topic, but let me share quickly.
I think lock timeout is named very wrong.
Very wrong.
Because it's not lock timeout, it's lock 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 a lock acquisition timeout.
Do we want lock timeout?
Maybe no.
Maybe log 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.
Michael: By the way, I think I agree on your overall sentiment
that there's no 1 huge feature in Postgres 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 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 release notes.
1, I think is in most Postgres releases, but there's a lot of
performance improvements.
A lot, 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 1.
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.
Nikolay: I agree as well.
Yeah.
And it's it continues to be so in 16.
We had also a lot of improvements.
Anything particularly you want to discuss in these 2 areas?
Michael: So performance, I'm gonna point people towards the blog
posts.
I think the crunch data 1 in particular is brilliant and Basically,
the summary of that is for certain I think largely They I think
they might that might be a Rails application.
If not, I think it's an ORM based 1.
I need to check.
But for certain workloads, even the preliminary work that Peter
Geoghegan and Matthias van de Meent have done, Obviously, Peter said
it could be any amount, but it could even be 20 to 30% on some
workloads globally, like across the whole workload.
I know individual queries could be no faster or thousands of
times faster depending on the individual cases.
But those kinds of numbers, 20 to 30% on a real endpoint, is
massive.
Like that, 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.
Nikolay: 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?
Michael: 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 the, like some defaults
have been changed as 1 that's been bumped from 256 kilobytes
to 2 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, the men, what Melanie
did should really help with huge tables.
So yeah, there's, there's tons of improvements around that stuff.
At the parallelism 1, 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 upgrades, and those are always really helpful and encourage
others to upgrade as well.
Nikolay: We already started talking to our AI assistant, like,
let's benchmark something.
And, like, I maybe should start this work earlier, but maybe
now we will find some examples.
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.
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 live system, how to extract a piece of it and
then have fake data and so on, it's like always tricky.
But I think something in the area of vacuuming definitely should
be analyzed.
For example, I remember 1 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 yeah, but this
is 1 of the things to check maybe right?
Michael: It must be rare to have tables without indexes, but
I imagine that people have done that extremely deliberately,
like Anybody that does have a table without indexes, that means
there's no primary key.
There's so many...
Nikolay: Yeah, no logical...
Michael: What?
Yeah.
Nikolay: If you don't use a replica identity full, which is not
good sometimes, and so on.
Yeah.
So you mentioned some settings, and I must return to Andrei Borodin
and another his contribution, which was under development many
years.
This is ability to configure the size of various SLRU caches.
I think 2021 I wrote this article, right?
It was related to incidents GitLab had with sub-transactions.
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 We had long transactions, we used
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 tested the patch and
we tried to understand how the bigger size of SLRU cache will
help.
And in some cases it helped, but I made it 3 years ago already,
so I don't remember all the details, but as I remember, it was
tricky.
Not like linear effect.
You double this and you have 2 more seconds until the problem
hits you.
So I think this is a good area also to check, but it requires
a 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
overflow, we can just increase it, right?
At least to postpone this, like to shift this cliff and think
how to improve and avoid it completely.
Michael: Yeah, it's really cool.
I see that, reading the release notes, I see that it comes with
7 new parameters.
Nikolay: Yeah.
Michael: But crucially and I think this I think this is really
important 3 of those scale up automatically with shared buffers.
Nikolay: Yeah that's really cool.
Michael: But that means 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.
Nikolay: Yeah, I wanted to check why upgrade by depesz, which
also provides the list of configuration changes, but unfortunately,
it doesn't support 17 yet.
Michael: I meant, well, we're bear in mind, we're recording a
few days ago.
So there's a very good chance that depesz is great at new version
support.
Nikolay: I always use that tool and that website and suggest
our clients to use it.
So it's very helpful indeed.
Yeah.
So what else?
What else do you want to discuss in this release?
Michael: 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.
Nikolay: Yeah, that's great.
In 16, it was already possible to use logical slots on physical
standbys.
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 in Patroni this problem was solved.
But now it's solved in core, in 17, so if a lower is not a headache
anymore.
But I must admit, logically it's tricky.
There are many issues, and like, not obvious issues sometimes.
As I remember, the problem with restarts is not yet solved.
The problem with duplicates.
During restart, you might see the 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 end up having duplicates.
I think this problem is not, it's maybe a 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 in
this area.
Michael: Well, and we were talking just before the call, like
there are still the major limitations 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 gonna...
Nikolay: Because there's work in progress.
Yeah, commit fests 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 is
waiting for review.
So let's advertise it.
If someone wants to help, this is a good point.
And people need it.
1 of the biggest concerns with logical is lack of replication
of sequences DDL and the third 1 was fell over but finally 17
solves it but we had some like 5 minutes of preparation before
the show and you mentioned that this feature ah no there is 1
more sorry upgrades right you mentioned about upgrades
Michael: yeah
Nikolay: so slot is not lost so it is not lost when I'm great
you upgrade.
This is another big thing, because usually if we perform a 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.
Michael: Yeah, exactly.
Or from 17, whichever, yeah.
Nikolay: We cannot upgrade from 17 yet, anywhere.
Michael: Exactly.
Nikolay: So we cannot use this feature this year, basically,
at all.
Michael: But it makes sense, like, this is how it had to be implemented,
right?
Like, unless you backpatch it.
Nikolay: Strategic move, right?
Michael: 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.
It takes 5 years, but that can fly by.
So I imagine we'll be using that quite soon.
Nikolay: Yeah, can you imagine I like...
Yeah.
My contribution, XML, not mine, like I was a little bit...
I know
Michael: what you mean.
Nikolay: But it was 8.3.
Yeah, wow.
Michael: 2008,
Nikolay: so yeah.
I'm already...
Yeah, and there are people who?
Remember even the beginning so yeah, it's interesting how many
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_wait_events view is called so.
And this is a dictionary.
This is like just a list of...
Of course we need a dictionary because so many wait events, right?
Michael: 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,
Nikolay: that's great,
Michael: but that is a really cool.
Nikolay: But it's like there is pglogs for example and it's not
a list of logs.
Michael: I see what you mean.
So
Nikolay: something is with naming.
Like naming is 1 of the 2 hardest computer science problems we
know.
Okay, so that's it.
Like this is my feedback.
It's great to have a list, but maybe yeah, I expect some confusions
in this area.
Michael: I think naming is hard even in a project where you have
like 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 1 that more people could have caught, But I think
it's extremely hard in a distributed project.
Nikolay: And in this area, another example of issues with naming
is there is a wait event called 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.
PASH Viewer does it.
This is Java application, which is very useful if you don't have
persistent monitoring and just ad hoc.
Michael: You
Nikolay: can use that as an ad hoc tool.
And they say CPU.
Michael: Yeah, I remember that.
Nikolay: 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, ah, yeah, extension to define custom wait events it's
great
Michael: yes
Nikolay: 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.
Michael: I blame the monitoring systems for that not yeah.
Nikolay: Yeah.
Yeah, of course, of course It's like this.
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.
Wait event is null 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 is
not yet defined.
Michael: Or unknown.
Nikolay: Unknown, right.
This is null meaning unknown.
Well, maybe, yeah, it's hard.
But because it's about code coverage, we need to cover more and
more code with weight event analysis, which is great.
I was super skeptical 3, 4 years ago.
Now I think weight event 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 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 Munro.
So it means that before 17 it was null, right?
And in monitoring it was CPU.
There's big confusion here.
So what should be done in documentation, probably it should be
saying, as you said, or unknown, or unknown wait event.
But in monitoring systems, it should be CPU or some unknown wait
event.
But recently I participated in some design of the board and like
we discussed this and it's really hard like it's very tempting
to pull just 3 letters CPU and that's it but at least it should
be CPU like you know asterisk and some remark somewhere right?
Michael: I think so it depends I find this is like a really difficult
1 where you want to 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 1 of those cases where it might be harmful.
But yeah, tricky 1.
Nikolay: But it's great that This is extended.
It's great that we have a dictionary of all the events now.
And it's also great that extensions can extend this wait event
list additionally.
We already saw pg_stat_statements wait event, I think, starting
in 2016 or 2015.
Because before it was also null and CPU, but then you see, oh,
It's contention at pg_stat_statements.
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 a CPU maybe.
We can name it CPU maybe in parentheses.
Right?
Michael: Yeah, I quite like that.
Yeah, or probably.
Nikolay: Yeah.
But we will discuss that it's CPU and it's actually doing some
work, but maybe it's some wait event which is not yet already
defined, right?
So yeah, it's interesting.
Many small changes, including in observability related things,
like I expect monitoring systems will deal with renaming and
so on again.
Michael: And Lots of changes there, to be fair.
And even to the views, there's 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.
Nikolay: I wanted to congratulate Andrei Borodin, and also I
wanted to congratulate all checkpoints, which now have their
own system view pgstat_checkpointer.
The first to leave, like, information about checkpoints was always
in pg_stat_buffercache, which was ridiculous and unclear.
I saw many confusions.
Finally, it's resolved.
Great.
Michael: Was it in bgwriter or...
Nikolay: bgwriter, sorry, not buffercache.
I was just looking at...
Yeah, Background Writer, which is like additional mechanism,
but checkpointer is the main mechanism, right?
But stats for both until 17 was present in pg_stat_bgwriter.
Now we have 2 separate system use and no more confusion, which
is great.
But more work on shoulders of monitoring system developers.
Michael: 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 pgwatch2 and they've got a branch for
it, I don't know if it's been merged yet.
Nikolay: pgwatch2
is dead.
pgwatch3 is being developed and it was renamed to pgwatch
without numbers.
Michael: Oh cool, well on their pgwatch2 repository.
Nikolay: Okay it's not dead but the focus is yeah.
It's not bad, like recently I guess Paolo Golub renamed it to
pgwatch without numbers so no more confusion in the future but
as I understand it's not yet fully released and it may be it's
maybe what you talk about is in the old pgwatch2 and we
maintain the fork of pgwatch with our own dashboards looking
forward to merging efforts, uniting efforts in the future with
main pgwatch.
Michael: Before you have to add Postgres 17 support yourself?
Nikolay: 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,
Michael: so it's because it's
Nikolay: quite mechanical, this change.
Michael: 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 1 I end up using the most.
And I don't know if you saw this, but you can now provide parameters
to the random function.
And you can do them, for example, in integers.
So you could do random 1, 100, and you get a random integer between
1 and 100.
Nikolay: Yeah.
But it's just syntax sugar, it's convenience.
Michael: I know, I know.
But I think the amount of times in example code and writing or
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.
Nikolay: Yeah, also, let me let me return us to the area of confusion
resolution.
I remember how I shoot several feet of myself in the past using
hyphen D originally with psql because it's database right like
it's it's not not convenient to specify database without any
options. So I got used to using the "-d" database.
And then, suddenly, I had some nasty situations when with pgbench,
if you use "-d," something goes very wrong.
Because there it means debug.
Michael: Oh.
Nikolay: Yeah.
It was interesting, I remember.
So Postgres 17 resolves this.
"-d" means database in both utilities now.
Michael: Even in pgbench now, wow.
Nikolay: Yeah, and "--debug" is the new option for pgbench.
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.
Because yeah, okay.
Michael: Well, it's reduction reduced still
Nikolay: Balance is positive. That's great.
So yeah.
Michael: Awesome.
Is there anything that you'd warn people?
I like to encourage people to upgrade to the major versions.
But mostly because I see people overall having a little bit too
much reticence to do so.
They treat Postgres like most projects and are very, very cautious
on upgrades and often lag several versions behind.
So I like to push people to upgrade a bit more.
Nikolay: Of course.
Of course.
It's worth upgrading non-production environments already, like
basically now, but on production and on production environments
it's worth upgrading when it will be 17.1, 17.2.
And 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.
Michael: 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.
Nikolay: It happens sometimes, but still, my recommendation for
critical, super important clusters, I would wait a little bit,
or perform very thorough testing myself, I mean myself with my
team and only then upgrade because jumping straight to 17.0 in
critical production, it's sounds crazy and any SRE or DBRE will
admit it.
This is a 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.
Michael: 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
Nikolay: 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 benchmark 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 a super easy before AI and I hope we
will find some problems and report
Michael: yeah the main read like obviously there's risks but
there's also it's well worth checking support from tools you
use, like extensions often, a lot of ones I checked haven't yet
announced Postgres 17.
Many do, but many don't as well.
Yeah, but many do.
Nikolay: A few days ago I approved a merge request for DBLab engine.
And we have extensions, a lot of extensions in our custom images
for Postgres.
And I saw on this, like I expected much longer list of unsupported
in 17, but it was like 5 items only.
We have dozens of good extensions, additionally, to contrib modules.
Michael: Well, some that don't, for example, I didn't see, did
you see Timescale or Citus?
I didn't see that.
Timescale was not
Nikolay: there, I think.
Yeah, it's big.
It's big.
Let me.
Michael: pg_repack as well, I didn't see.
Yeah.
Like these are, these are ones that it doesn't matter to somebody
if most of their extensions are supported.
If there's 1 that they're using that is critical and it's not
supported, then...
Nikolay: Yeah, I'm looking at the list and yeah, indeed,
pg_repack, pg_qualstats, it's PoWA, and Timescale, Citus, you're
right.
Michael: 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...
Go on
Nikolay: pgvector is fine.
It's already
supporting 17.
Michael: Yeah, and lots of other tools have already, like we
shipped Postgres 17 support the other day.
Patroni as well, version 17 support already.
Like loads of tools do, which is great.
But yeah, I just thought it's worth saying it's worth people
checking that the tools they rely on do support it already.
Nikolay: Good.
Okay.
Michael: Nice.
Anything else you wanted to say?
Nikolay: No, I think that's it.
Upgrade, but carefully.
Michael: Yeah.
Or at least check out the release notes and see if there's anything
important in there for
Nikolay: you.
Right, right.
Good.
Thank you, Michael.