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.

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.