Nikolay: Hello everyone, this is PostgresFM, a podcast about,
guess what, Postgres.
I'm Nikolay and hi Michael.
Michael: Hello Nikolay.
Nikolay: How are you doing today?
Michael: I'm good, thank you.
How are you?
Nikolay: Very good.
So we discussed before the call that we have a few options for
topics.
And it was my choice, but somehow you chose, right?
You chose the health check or checkup.
Postgres health checks and how to check the health of Postgres
clusters periodically, why to do so, what to look at and so on,
right?
Michael: Well you said you had 2 ideas, 1 of them was this 1
and I was like I like that idea And then you explained the other
1.
I was like, I like that idea too.
So I think we've got lots of good ones left
Nikolay: to go.
Yeah.
We need to discuss the internal policy.
How transparent should we be?
Right.
Michael: Yeah.
Well, and nice reminder to people that you can submit ideas for
future episodes on our Google doc or by mentioning us on Twitter
or anything like that.
Nikolay: Right.
Right.
That's, that's good.
We, I, I know people go there sometimes and I think it's good
to remind this, this, this opportunity and this, this feeds our
podcast with ideas.
So, yeah, good point.
So, health check, where to start?
Goals, maybe, right?
Or...
Michael: Well, I think definitions, actually.
I think, because I was doing a little bit of research around
this, It is a slightly loaded term.
When you say health check, it could be for example software just
checking that something's even alive, but all the way through
to kind of consultancy services around, you know, that kind of
thing.
Nikolay: Select 1 is working.
That's good.
Michael: Yeah, So what do you mean when you say health check?
Nikolay: My perception on this term is very broad, of course.
Because in my opinion, what we mean is not like looking at monitoring
and see everything is green or something, no alerts or nothing.
No, no, no.
It's about something that should be done not every day, but also
not once per 5 years, slightly more frequently, right?
Like for example, once per quarter or twice per year.
And it's very similar to checking health of humans or complex
technology like cars, right?
Sometimes you need to check.
And it doesn't eliminate the need to have continuous monitoring.
Like, for example, in your car you have various checks constantly
being working, for example, tire pressure.
By the way, I think for humans it's a big disadvantage that we
don't have monitoring.
It's improving, for example, a modern smartwatch can provide
you a heartbeat rate and so on.
But still, we're monitoring...
When I complain about how poor some Postgres monitoring systems
are, I remind myself how poor human body monitoring is right
now still.
And we can monitor technological systems much better than non-technological.
So yeah, we have some things constantly being checked, but still
we need sometimes to perform deeper and wider analysis for different
goals.
First goal is to ensure that everything currently is fine and
nothing is overlooked.
And second goal is to predict and prevent some problems in the
nearest future.
And the third goal is things like how we will live in the next
few years.
It involves capacity planning and proper planning of growth,
and prediction, and so on.
So these are 3 key goals, very roughly, right?
What do you think?
Michael: Yeah, I really like it, and I think the car analogy
is particularly good in that I don't think this is true in the
US but in the UK at least, once a car is a certain age, like
3 years old or something, it's required by law to have an annual
health check, we call it an MOT, but it's not just what's wrong
with the car now that you need to fix, but it's also looking
at what like things that could go wrong and making and trying to
get them replaced before they fail.
So there's there are certain parts of the car that if they haven't
been changed in a certain number of years They have to be changed.
So I think that's quite a nice kind of that's at least 2 of the
goals looking at What's wrong now, but also if we don't do anything
about it what could go wrong very soon and we should get ahead
of it, which is not necessarily something monitoring always is
good at.
Nikolay: Yeah, well, in the US it's very different.
No pressure at all.
You just change the oil and that's it.
Everyone is on their own, as I understand, at least in California.
And actually, I'm going to argue with myself and with you a little
bit.
Better technology means less need for health checks.
For example, I own a couple of Teslas, and I was very concerned
that nobody is replacing anything like filters and so on and
then I needed to replace the windshield after some trip
to Nevada. And I asked like guys, like check everything like brake
pads and so on because of course I'm worried like it's already
like almost 2 years and nothing and they said everything
is fine we are going to replace just the cabin filter and that's
it. No need to replace anything because it's better technology.
So I think, of course, the amount of work that needs to be done...
Let's go back to Postgres because it's a PostgresFM podcast, as
I said in the beginning.
So, if we have very old Postgres, it probably, it perhaps needs
more attention and work to check and maintain good health.
Michael: I think there are 2 axes.
I think you're right that technology plays into it, but I think
also simplicity versus complexity plays a part as well.
And as Postgres gets more complex or as your Postgres setup gets
more complex, I think actually maybe there's more you need to
do, whereas on the car analogy, I think one of the arguments for
things like electric cars is they're simpler.
They have fewer parts.
They are easier to maintain.
So I think there's also an argument for keeping your Postgres
setup.
This is one of the arguments for simplicity in, well, we'll get
to some of the specifics, but on the technology side, for example,
if we could get bigger than 32-bit transaction IDs,
Nikolay: we
Michael: wouldn't have to monitor as often for wrap, like wrap
around would be less of an issue.
If we defaulted to int8 or bigint primary keys instead of int4,
we don't have as many of those issues.
So, by certain choices, we can simplify and prevent issues, but
also the technology.
Nikolay: And defaults matter a lot.
Defaults matter.
If, for example, all our application code or frameworks, and
for example, Ruby on Rails made this choice a few years ago.
As you said, default to bigint for surrogate primary keys,
then minus one report needed, right?
At least, yeah, so we don't need to check integer capacity
for primary keys.
And that's good.
But of course, the complexity of the system can grow and sometimes
we check in Postgres help, we go beyond Postgres, for example,
we check connection pooling and how orchestration and automation
around Postgres is organized with the goals to understand the
HA, high availability, disaster recovery, these kinds of topics.
So and of course capacity planning.
We will grow a few years without performance issues or not.
But anyway, we can add many things like that.
For example, if threads topic succeeds, started by Heikki a year
ago, if this succeeds, we won't be worried about single CPU core
capacity for system processes.
Or for example, there is an ongoing discussion for pgBouncer that
threading is also a good thing, so we won't be bound, the process
won't be bound by a single core, and this is a hard wall to hit.
And Postgres processes can also hit, some Postgres processes
can hit single core utilization 100% and even if you have 100
more cores, it doesn't help you, right?
So if, like, I cannot say this is simplicity because technology
is similar to EEV It's also like a lot of complex technology
behind it but it's simplicity of the use, right?
Of usage, maybe.
Michael: Well yeah, I would actually argue that let's say we
did get threading in Postgres in a major version in a few years
time.
Actually, at first, you'd want to be doing health checks more
often.
You'd be more nervous about things going wrong because you've added
complexity and things that maybe for over a decade have been
working great suddenly may not work as well or just their
patterns may change
Nikolay: Well maybe, maybe, but let's let's find some mutual ground
here maybe like we both agree that health checks are needed,
right?
Or right now at least.
Maybe in Postgres 25, it won't be needed so much because it will
be an autonomous database.
Michael: I personally, I think it's a really good way of keeping
a system reliable and avoiding major issues including downtime
and outages and huge things.
But that's, yeah, I don't need it as an interesting word.
Like a lot of the people I see hitting issues are just living
in a reactionary world.
A lot of them are startups and they.
Yeah.
But once like once things are working well and you've got, like
maybe you're hitting like an inflection point or you need to
capacity plan or you're in a large established business where
outages can be really expensive, it seems wild to me to not be
doing semi-regular or if not very regular health checks.
Nikolay: Right.
Yeah, I think you're very right.
There are two categories of people who, for example, go to us for
health checks.
One is probably the bigger category of people.
People who knew that it's good to have a health check, but they
only come to us when something happens, something bad happens,
something already hitting.
And in this case, well, it's actually like a psychological thing,
right?
For example, for a CTO, the Postgres database is just one of the things
in infrastructure.
And when it hurts, only then we realize, okay, let's check what
can hurt soon as well, what other things can be a problem in
this area, Postgres, right?
This is a very good moment to perform a health check.
Another category is, I would say, wiser guys.
They do health checks before a launch or in the initial stage,
but at the same time it's harder to work with them because usually
the project is smaller, and it's harder to predict workload patterns,
growth rates, and so on.
But this is better, of course, to start checking health initially
and then return to it after some time.
Michael: Yeah, it can go hand in hand with, like, stress testing
as well.
Can't it?
Like before I see a lot of people doing this kind of thing before
big events, like in the US you've got Black Friday, Cyber Monday
peak times where you know there's going to be increased traffic
or increased load.
Before that, there's a lot of work that people are doing often
to just make sure they can.
Is that a good time to do a health check?
Nikolay: Right.
Well, yes, but I would distinguish these topics.
Load testing and preparation for some events like Black Friday
is something else.
Health checks, as I see them, doing for many years, it's quite
an established field.
They include review of settings, review of index health, bloat
first, let's talk bloat first, both table and index B-tree, then
index health, and we had an episode about it, we had an episode
about bloat, about index health and maintenance then query analysis,
like do we have outliers who are attacking us too much in various
metrics I mean queries in pg_stat_statements and other extensions
Then static analysis, for example, you mentioned int4 primary
keys, lack of foreign keys and so on.
Because if we see it first time, a lot of findings.
If we see it a second time, maybe since last time, developers added
a lot of new stuff, right?
And other areas as well.
And capacity planning can be strategic, like many years, or it
can be before some specific event like Black Friday for e-commerce.
In this case, it may involve additional actions like let's do
load testing, but I would say health check, normal health check,
is a simpler task than proper load testing.
That's why I'm trying to say it's a separate topic, because if
you're involved, a health check suddenly becomes bigger.
You can think about it, if you go, like in the US, if you go
to a doctor, there is an annual health checkup, covered by insurance
always, right?
So, it's like your primary care physician doing some stuff, discussing
with you, checking, many things actually, but it's not difficult.
And then if there is some question, you go to a specific doctor.
And load testing is a specific doctor, I would say.
Michael: Yeah, I was just thinking about timing, if it's more
likely that people start the process then.
And just like maybe just before they go on a holiday maybe they
go for their annual checkup or like I don't know if there's like
times where people are more likely to go for those than others
but yeah should we get into some more specifics
Nikolay: yeah well speaking of time to finish this topic Sometimes
people just have periodical, you know, like, life cycle episodes
in their work, right?
For example, this financial year, right?
And you plan finances, you spend them, and so on.
You manage them.
Similar proper capacity planning and database health management
should be also like periodical.
You would just have some point of time, maybe after some events,
for example, after Black Friday, you think, okay, next year,
how we expect our growth will look like, how we expect our incident
management will look like.
And this is a good time to review the health, understand ongoing
problems and try to predict future problems.
You also perform capacity planning to understand do we need to
plan big changes, like architectural changes, to sustain the
big growth if we predict it in a couple of years.
In this case probably you need to think about microservices or
sharding or something like that.
And health check can include this, like overview.
And this is a big distinction from monitoring, because monitoring
very often has very small retention.
You see only a couple of weeks or a couple of months, that's
it.
For an existing evolved system, you need a few years of observation,
data points, better to have them, right?
To understand what will happen in the next years.
And this is when like a health check can help and capacity planning.
Maybe load testing as well, but it's additionally, I would say.
Yeah, specific topics.
So the tool starts usually for me specifically.
We actually have this tool, Postgres Checkup and it has a big
plan.
The tool itself implements only, I would say, less than 50% of
the plan.
The plan was my vision of HealthCheck several years ago.
I did conference talks about it.
At that time, I remember I performed really heavy health checks
for a couple of really big companies.
It took a few weeks of work.
It's like a lot, like deep and wide, and like 100 pages report,
PDF of 100 pages, it's like interesting.
Executive summary alone was like 5 or 6 pages, like quite big.
Wow.
Yeah, yeah, well, it's a serious thing.
But it was for a company which costed more than $10 billion.
And the Postgres databases served a few clusters that were
in the center of this serious business, so it was worth it.
And then this tool, this was the vision, and we implemented in this
tool, we implemented like almost half of this vision.
And for me everything starts with version.
Simple thing.
Let's check version.
Major and minor.
And maybe history of it.
Because both things matter a lot.
If your current version is 11, you're already out of what?
Out of normal life, right?
Because the community won't help you, and bugs won't be fixed unless
you pay a lot.
Michael: And out of security patches as well.
Nikolay: Right, yeah, that includes security also, bugs.
If you're on 12, you have time until November, right?
So, major version is important, and also you are missing a lot
of good stuff.
For example, from one of recent experiences, if you're on 12, it
not only means that you soon will be having non-supported
Postgres, but also you lack good things like WAL-related metrics
in pg_stat_statements and explain plans, which were added in the next
version, 13, right?
You lack a lot of improvements related to logical decoding and
replication.
Probably you need to move data to Snowflake or between Postgres
to Postgres and you miss a lot of good stuff.
So major version also matters a lot, but the minor version may be
number 1 thing.
If you also lag in minor version, obviously you probably miss
some important fixes and security patches.
So here our tool is using yupgrade, depesz.com, links to explain
what...
Yeah, it's a great tool, but now we're already moving towards
combining...
It's a huge list sometimes, right?
If you're lagging 10 minor versions behind, it's more than a
couple of years of fixes.
And you're like, oh, what's important here?
Security, but maybe not only security.
So, yeah, we are moving towards trying to summarize this and
understand particular context.
Of course, guess what helps?
LLM helps here.
Like it's, yeah, I think in the nearest future we will have interesting
things here like combining observations, why upgrade this diff,
and like this is summary what matters for you, like almost part
of executive summary can be read by CTO and with links, so like
it's not like...
Yeah
Michael: I hope you're right long term, but I think at the moment,
the release notes are important enough like the risk of missing
something very important is still very high.
Like I think sometimes the LLMs at the moment still, they can
be good for like idea generation, but if you want an exhaustive
list of what's very important, they can miss things or make things
up.
So I would still not rely on them for things like reading, which
like even minor release notes can include things that are very
important to do, like maybe a re-indexing is needed and things
like that.
Nikolay: Yeah, I agree with you, but I think you are criticizing
a different idea than I'm describing.
I'm not saying, like, first of all, health checks we are doing
and I think in the next few years we'll be doing them still a
lot of manual steps for serious projects.
So they, of course, involve DBA who is looking at everything.
But LLM can help here.
You have usually pressure of timing.
You need to do this work and a lot of stuff.
And change log with 200 items, for example.
Of course you check them, but I bet no DBA spends significant
time to check properly.
They said they check, but I don't trust humans as well here.
Michael: So sorry, I think including them in a report is different
to reading them before upgrading.
That's a really good point.
Nikolay: Right, so what I'm trying to say, we try to convince
clients that it's important to upgrade, both minor and major.
And while explaining, of course we can provide, not we can, we
provide the list for full changes, why upgrade is great too.
But also we want to bring the most sound arguments, right?
And OLM helps to highlight.
It was my long-term vision a few years ago.
I thought, why upgrade?
You take it and it would be great to understand.
There is an item about GiST indexes, or GIN indexes, for example.
We have a schema here, we can check if we have GIN indexes, right?
Does it affect us?
And if it does, this should be highlighted.
This is the idea.
And LLM is good here.
It's like it just performs some legwork here.
I mean, not only LLM, some automation with LLM.
And it just helps DBAs not to miss important things, you know?
But of course, again, I'm sure it should be combined, like ideally
it should be the work from automation and humans.
Okay, too much for versions.
Actually, it's the smallest item usually, right?
We don't have time for everything else, what to do. Okay, let's
let's speed up maybe a little bit.
Michael: I think we've mentioned a bunch of them already, haven't
we like you've done
Nikolay: Yeah, but right.
We had episodes separately, but they are super important.
Settings go usually second.
Settings.
It's a huge topic.
But, from my experience, if I see autovacuum settings being
default, or checkpoint settings, first of all, max_wal_size,
in my opinion, the most important one, being default 1 gigabyte,
or logging settings being default.
What else?
These kinds of things.
Michael: We did a whole, We've done one on the default configuration.
Nikolay: Our favorite, random_page_cost being 4.
Recently we discussed it.
These are strong signs to me that we need to pay attention here.
Even if I didn't see the database yet, I already know that this
is a problem.
Michael: So this is really useful for that first health check
you ever do.
Maybe you're a new DBA or new developer on a team.
When you're doing a second health check or subsequent ones, are
you diffing this list of settings and seeing what's changed in
the last year?
Nikolay: Good question.
We have reports that can help us to understand that, for example,
checkpoint needs reviewing, reconsideration, checkpoint settings,
or autovacuum needs reconsideration.
So yeah, you're right.
I'm just coming here with like, I first met this database and
reviewed it.
But yeah, second is easier usually, but if it grows fast, it
can be challenging as well.
So sometimes we need to revisit.
Yeah, but settings, it's a huge topic.
I just wanted to highlight the easy, low-hanging fruit we usually
have.
Default is a low-hanging fruit.
For example, if the auto_vacuum scale factor is short or regular,
it's default like 10%, for any OLTP database I would say it's
too high, way too high.
So many things like that.
And logging settings, if I see logging settings are default,
I guess people don't look at databases properly yet and we need
to adjust them and so on.
But second time is easier usually, I agree.
Second time you just revisit things that change a lot.
So, bloat estimates tables, indexes.
Quite easy, right?
We usually don't want, very roughly, we don't want anything to
be higher than 40-50%.
Depends, of course, but this is normal.
And converting to number of bytes always helps.
Like, people say, oh, my database is 1 terabyte, and I have like
200 gigabytes of table and index bloat.
Wow.
Of course we have this asterisk like comment, remark that it's
an estimate, it can be very very wrong.
We discussed, we had an episode about bloat, and autovacuum
as well, very related topic here.
And then from table bloat, index bloat, from index bloat we already
go to index health, which is of course index bloat included,
But also unused indexes, redundant indexes, well, rarely used
indexes, like it's a rarely used report.
But also invalid indexes, unindexed foreign keys.
What else?
Maybe that's it.
Michael: Are you overlapping?
Nikolay: Redundant, we call that redundant.
So yeah, and we suggest talking about index maintenance and I usually,
if it's the first time, I explain why it's so important to implement
index maintenance and why we should understand that we do need
to rebuild indexes from time to time.
Michael: Are you doing any corruption checks?
Or I'm guessing maybe not in this case.
Nikolay: Oh, that's a great question actually.
I think we can include this, but a proper check is quite heavy.
Michael: Yeah.
And one of the nice things about this tool is it's like a lot of
these, it's been designed to be lightweight in this case, right?
Nikolay: Yeah, it's very lightweight.
It was better tested in very heavily loaded clusters.
And it limits itself with statement timeout like 30 seconds or
even 15.
I don't remember from the top of my head, but if it takes too long,
sometimes we just miss some reports because statement timeout.
We don't want to be a problem.
Observer effect.
Michael: Yeah.
Nikolay: So, yeah.
And if we talk about indexes, okay, index maintenance, quite
straightforward topic already, quite well-studied.
And of course, we don't forget replicas, and we also don't forget
about the age of statistics, because if it was reserved yesterday,
we cannot draw proper conclusions, right?
Because maybe these indexes were not used in the last 24 hours.
But okay, anyway, we had the index maintenance episode.
Yes.
Michael: I have a couple of questions.
I have a couple of questions on the cluster health.
So, replication, are you looking at delay at all?
Or what are you looking at when it comes to replication health?
Nikolay: That's a good question.
I doubt we have replication lags being checked by this tool at
all.
It's usually present in monitoring.
So as part of broader health check, not only we use health
check, but the postgres-checkup report, but we also talk with the
customer and check what they have in monitoring, and sometimes
we install secondary monitoring, which we have, and gather at
least 1 day of observations and include everything.
And also discussion matters.
This is probably what automation won't be having anytime soon,
is live discussion, trying to understand pain points, like what
bothers you, what is the issue recently, what issue do you expect
to happen soon.
This live discussion at a high level may help prioritize further
research.
So proper health check includes both automated reports and these
kinds of...
So there we can check replication, but usually if people don't
mention replication lags being an issue, they have it in monitoring,
we just skip this, usually.
Sometimes they mention, for example, a lot of WAL is generated
and we say, okay, let's go to pg_stat_statements and check WAL
metrics, try to understand why we generate so much WAL, optimize
some queries, enable WAL compression if it's not enabled, and
so on and so on.
Also, disk, let's just check what kind of disks you have.
It's a big topic.
Michael: Yeah, the last question I had was another thing that I imagine
is very important to check the first time you want to know the
overall system health, or at least setup health, but might be
tricky to automate or quickly run a query for, is what's the
health of the backup process or
Nikolay: the risk?
You're raising questions.
Yeah, if you check the plan, which is in the readme of the postgres-checkup,
this is included there, and the checkbox is not checked,
of course.
Michael: Oh, okay.
Nice.
Nikolay: Yeah, we thought about automating this, but we have
so many different situations, different backup tools used, different
managed providers and so on.
Every time it's quite different.
We have a wide range of situations.
Michael: Yeah, I wasn't actually thinking about postgres-checkup
at all, I was thinking more about health check.
As part of a health check, you'd probably want to check you can
restore.
Nikolay: Did we have an episode about backups and disaster recovery
at all?
If not, let's just plan it.
Because it's not a topic for 1 minute, it's a huge topic and
probably...
Michael: Of course.
Nikolay: Yeah, maybe number 1 topic for DBA, because it's the
worst nightmare if backups are lost and data loss happened, right?
Obviously, we'll include this to consideration unless this is
managed service.
If it's managed service, we have guys who are responsible for
it, right?
Well, it brings us to this topic, managed versus self-managed.
Because for example, HA, since not long ago, both RDS and GCP
CloudSQL, they allow you to initiate a failover to test it.
So, you rely on them in terms of HA, in terms of if 1 node is
down, a failover will happen.
But you can also test it, and this is super important.
Backups, it's like a black box, we cannot access files as we discussed
last time.
But you can test restoration, right?
And it's fully automated.
And maybe you should do it if you have a serious system running
on RDS, because as I understand, RDS itself doesn't do it for
you.
They rely on some global data, as I understand.
They don't test every backup.
Michael: All I mean is if I was a new DBA going into a new company
and I want, like 1 of my first tasks was to do a health check,
this, that would be 1 of the things that I would think of as
including as in that health check.
Maybe a new consultant would as well.
Nikolay: DR and HA, two fundamental two-letter terms, right?
You definitely, if you're starting working with some database
seriously, you definitely need to allocate a good amount of time
for both these topics.
Like good means at least a couple of days for both to deeply
understand what...
For example, if we talk about backups, you need to understand
RPO, RTO, real and desired, to check if we have a document, where
it's documented and procedures defined to maintain these objectives.
These are super serious topics and for any infrastructure engineer
I think it's quite clear, for any SRE it should be quite clear
that these are two SLOs that you need to keep in mind and always
revisit and maintain and have monitoring that covers them and
so on.
But this is again, like this is maybe...
In health check, we just need to check and understand if there
is a problem here.
To study this topic is similar to a lot of testing topics.
It's like a special doctor.
So yeah.
What else?
To wrap up, maybe a couple of final things.
I like to check query analysis in table form.
In table form it's quite exotic maybe because people got used
to some graphs of course, historical data, it's great.
But when I look at table data for pg_stat_statements with all these
metrics and derived metrics, it gives me a very good feeling of
what's called.
So to understand that, it's great.
And also static analysis.
Michael: Ordered by what?
Always ordered by total time.
Total time, I think, because we're looking at system-level health.
Nikolay: Yeah, yeah, yeah.
Total time is default for us because we talk about resources,
but if you aim to analyze the situation for end-users, you need
to order by mean time, and sometimes you need to order by different
metrics.
For example, as we discussed above, earlier, WAL metric, for
example.
Sometimes temporary files, for example.
If we generate a lot of temporary files, we want to order by
temporary files.
In this case, sometimes we just generate additional reports manually.
Michael: Yeah, makes sense.
Nikolay: And actually that's it.
Not difficult, right?
Michael: No.
Do you see a lot of people doing this in-house?
I know a lot of consultancies, including yourselves, offer this
as a service.
Do you see the pros and cons of those?
Nikolay: Well, usually in-house, if you do it forever, you don't
see problems, or you don't prioritize them well.
Because I saw we have bloat, but we have some kind of life still,
we are not down.
I saw we have, for example, 5 terabyte unpartitioned table, but
it's kind of fine maybe, and so on.
But when external people come, at least temporarily, or for example
you hire a new DBA, DBRE, this is a good point to revisit and
reprioritize things and avoid problems in the future.
So that's why fresh blood, fresh look is good here.
But usually people get a lot of value during first checkup, health
check, then smart people implement periodical health checks.
And then just, I would say, in 1 or 2 years, if things change
significantly, this is when you need to talk again.
Because if health check was full-fledged in the first year, 1 or
2 years will be fine and your team will be performing all the
problems, solving all the problems, knowing what to do.
Yeah, nice one.
But honestly, give me any database, I will find problems easily.
I mean, actual live production database, not some synthetic.
Anyway, like, summary is don't postpone this.
Perform health check, plan it and do.
Check your health.
Michael: I had one last thing to mention.
I met a few people at PG Day Paris, so hi to everyone who's listening
from there.
And if you're watching on YouTube and just listening to the audio,
we do also have an audio-only version in the show notes.
So you don't have to waste your precious bandwidth and data on
watching us.
And if you listened to the audio and didn't know we had a YouTube,
then now you know that too.
Nikolay: Right, right.
We also have a transcript if you like reading better and I think
it's quite good.
It's quite good.
Actually, guys who are listening, please check transcript and
let us know if you think it's good to read or it's hard to read.
I would like to know what you think about the quality of transcripts.
I was thinking about improving this and having some...
Not a book, but a kind of set of our discussions we had almost
last 2 years as just a set of texts.
Because some people just like reading, right?
So if people find the quality good, I think it's worth investing
to organize it better and maybe provide some more links and pictures
maybe and so on.
So this is the idea we discussed some time ago.
I think maybe I will pursue it soon.
But I need to know what people think about the quality of recent
transcripts we have on PostgresFM.
Michael: What's the best way to contact you for that?
Nikolay: YouTube comments, Twitter, all Twitter, right?
Michael: Yeah, yeah.
Nikolay: I think, yeah.
Michael: Nice.
Nikolay: Good.
Michael: Yeah.
Thanks so much, Nikolay.
Nikolay: Thank you, Michael.
Michael: Catch you next week.
Bye.
Bye-bye.
See you next week.
Bye.