►
From YouTube: GitLab 16.5 Kickoff - Database
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everybody,
my
name,
is
Roger
and
welcome
to
the
database
group
16.5
with
me
today
is
Simon,
who
is
our
team
staff
engineer,
hello,
Simon,
hello,
cool
so
with
16.5,
our
team
is
mostly
operating
at
full
capacity,
and
our
Focus
continues
to
be
effect
on
the
initiatives
that
affect
the
availability
and
reliability
of
gitlab.com
and
our
self-managed
instances.
We
continue
to
be
focused
on
our
medium
term
database
scaling
strategy
and
also
we
are
also
concerned
with
lightweight
block
contention
on
our
primary
database
and
something
we're
looking
to
mitigate
in
the
upcoming
Milestones.
So
for
16.5.
A
Our
top
priority
here
is
to
support
our
postgres
14,
upgrade
or
post
upgrade
sort
of
processes,
I
believe.
Over
the
past
weekend
we
have
cut
over
to
postgres,
14
and
I
know
we
did
a
dry
run,
we're
not
driving.
We
did
one
previous
effect.
We
had
to
roll
back
so
now
we're
officially
on
14.
A
B
Yeah
absolutely
so,
you
know
we're
running
on
a
new
version
of
the
database
software,
which
includes
new
features.
We,
before
the
upgrade,
did
a
lot
of
testing
to
make
sure
that
queries
would
perform
the
same
on
postgres
14,
even
though
it
has
new
features
which
might
impact
query
plans,
it's
possible
that
post
upgrade.
We
will
see
a
small
amount
of
query
plan
degradation
which
we
might
need
to
fix.
So
it's
important
to
set
aside
a
small,
a
certain
amount
of
time
for
that.
B
A
Oh
next
up
we
have
our
table
size,
reduction,
effort
and
I
know.
This
has
been
ongoing
for
quite
some
time,
both
in
terms
of
partitioning
and
some
of
the
lightweight
lot
contention,
as
well
as
mitigating
vacuum.
Time
pressures,
Simon
I
know
you
had
just
drafted
an
update
for
folks.
Do
you
mind
just
quickly
summarizing
where
you
think
we
are
at
and
what
are
some
of
the
upcoming
puzzles
here.
B
Yeah,
absolutely
so
in
16
4
I
analyzed.
How
often
are
we
actually
taking
lightweight
locks
across
the
database
replicas
and
the
primary
database?
This
is
difficult
to
do
because,
because
measuring
this
has
a
large
impact
on
the
performance
of
the
database,
so
we
need
to
synthesize
it
from
other
data
so
that
we
don't
actually
run
code
on
the
database.
So
I
have
a
good
idea
of
lightweight
lock
rates
on
the
database
and
I
believe
that
the
primary
is
well
below
the
saturation
metric.
So
we
don't
need
to
be
concerned
about
that
in
16.5.
B
I
want
to
validate
this
by
actually
running
a
test
at
a
low
traffic
period
to
make
sure
that
my
numbers
are
correct
and
I
also
think
that
we
can
start
to
remove
some
unused
indexes
from
the
namespaces
table
and,
right
now
it
looks
like
we'll
get
about
a
two
percent
Improvement
to
lightweight
lock
acquisition
rate
for
each
index.
We
remove
and
there
are
eight
indexes
that
we
can
remove
for
free
for
roughly
a
15
to
20
Improvement.
A
B
Yeah
absolutely
so
well
performing
partition
queries
that
only
touch
a
single
partition
do
not
have
an
especially
large
lightweight,
lock
impact.
However,
we
are
going
to
have
some
lower
call
rate
queries
in
partitioning
that
will
touch
many
partitions
and
have
a
large
impact
on
lightweight,
lock
rate.
So
this
will
provide
us
Headroom
that
we
can
then
use
in
partitioning
to
successfully
deliver
partitioning
without
causing
database
instability.
A
Oh
awesome,
thank
you
for
that.
So
next
up
we
have
primary
keys
that
we
wanted
to
upgrade
to
begin.
This
has
been
ongoing
for
quite
some
months
now.
I
think
the
biggest
part
here
is
we're
done
for
gitlab.com
and
we're
almost
done
for
self-manage.
I
won't
really
belabor
this
point
because
I
think
we
touched
on
it
for
quite
a
few
Milestones,
but
it's
exciting
that
this
is
going
to
wrap
up
soon
and
I.
A
Think
once
this
wraps
up,
we'll
probably
should
focus
to
help
support
some
of
these
partitioning
elements
as
well
as
the
database
testing
below
here.
A
Database
testing
is
something
we've
been
working
on
for
quite
some
time
as
well.
I
think
last
Milestone,
we
didn't
make
a
lot
of
progress
because
of
the
PG-14
upgrades,
so
I
think
we're
going
to
come
back
to
this
and
having
a
tangible
single
Report
with
newly
added
queries.
I
think
will
go
a
great
way
to
helping
us
validate
that
the
general
technical
design
works
and
Simon.
If
I
understand
correctly
I
think
with
this
Milestone,
it
will
also
give
us
the
opportunity
to
start
paralyzing.
Some
of
the
analysis
work
that
we
wanted
to
build.
B
B
Currently
we
can
do
that
for
migrations,
but
we
can't
do
that
for
one-off
queries
and
finders
and
web
and
Page
loads
and
things
so
getting
this
newly
added
queries
report
is
going
to
be
really
useful
for
database
reviewers
and
improving
database
review
across
gitlab,
and
it
also
can
be
spun
out
to
help
understand
how
queries
will
change
in
response
to
a
proposed
partitioning
strategy,
which
is
something
I'm
really
excited
about.
Yeah.
A
So
I
think,
if
I
could
summarize
that
on
a
high
level,
it
also
will
greatly
expand
the
surface
area
of
what
we
can
currently
look
at
and
cover
for
database
changes,
which
I
think
will
be
important,
given
that
tenant
sells
is
continuing
to
spend
quite
some
time
into
the
future
cool.
Lastly,
we
have
this
Focus
item
here
of
making
sure
migration
should
run
in
milestones
and
not
inversion
order.
I
think
this
is
something
that
we've
been
ongoing
for
quite
some
time
now.
A
B
I
think
cross
has
made
a
pretty
good
async
update
here
and
I.
Think
it's
I
know
in
164
he
had
a
spike
with
some
good
prototype
code
and
it
seems
like
it's
progressing
well,
so
I
think
people
can
read
like
was
successfully.