A weekly podcast about all things PostgreSQL
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.