►
From YouTube: GitLab 15.10 Kickoff - Enablement: 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
A
Cool
we're
going
to
talk
a
little
bit
about
the
database
group
and
what
we're
going
to
be
working
on
and
where
we
are
in
1510
we're
expecting
to
be
about
70
capacity,
while
two
of
our
team
members
proceeding
with
our
onboarding
and
ramp
up
and
we
hope
to
be
at
full
capacity
in
about
one
more
milestone
for
planning.
We've
got
a
number
of
top
priorities
and
as
well
as
a
number
of
high
severity,
Focus
items
that
we
want
to
share
with
everybody.
A
Let's
start
with
primary
keys
to
dig
in
Alex
I
know
this
is
a
thing
that
came
up
a
little
bit
last
minute.
Can
you
give
us
just
a
quick
history
lesson
here.
B
Yeah
so
gitlab
gitlabs
predates
gaylab
has
an
old
rails,
repo
and
early
rails.
They,
the
default,
was
four
byte
integers
instead
of
eight
byte
integers,
and
we
have
some
tables
about
a
year
and
a
half
ago
we
migrated
a
bunch
of
our
largest
tables
so
that
we
would
not
run
out
of
integers
in
them.
B
But
there
are
a
few
tables
that
still
have
four
byte
editors
that
we
didn't
migrate
and
we've
been
monitoring
those
over
the
last
year
and
a
half
and
they've
all
kind
of
hit
a
saturation
point
where
we're
a
little
concerned
about
them.
So
we
have
three
that
we
identify.
We
actually
have.
We
have
four
that
we
identified
as
high
priority
with
our
team
taking
on
three
of
them,
and
then
we
have
another
team,
that's
taking
on
the
fourth
one.
So
big,
thanks
to
the
pipeline
authoring
team
for
taking
that
on.
A
B
Yeah,
that's
correct,
so
we
have.
It
takes
a
minimum
of
three
milestones
in
order
to
do
these
migrations
because
they
they
have
to
run
in
the
background
and
they
we
we
have
to
wait
a
period
of
time
for
them
to
finish
migrating
before
we
upgrade
self-managed
customers,
because
they
can
only
upgrade
one
Milestone
at
a
time.
So
it
takes
a
little
bit
of
time,
which
is
one
of
the
reasons
that
we
really
have
jumped
on
this.
B
We
actually
jumped
on
it
Midway
through
the
last
Milestone
and
My
Hope,
Is,
that
this
will
only
be
one
or
two
a
theme
for
one
or
maybe
two
more
Milestones.
As
we
finish
the
cleanup
process,
yeah.
A
That
makes
sense
and
just
to
clarify
for
reviewers
as
well
so
like
we
are
already
creating
all
net
new
tables
using
eight
by
integers.
So
this
is
really
just
burning
down
old
tables
that
have
cropped
up
as
problematic.
But
you
know
we
don't
expect
this
problem
size
to
increase
over
time.
We
might
discover
some
new
tables
in
the
future,
but
we
believe
this
will
put
us
in
a
good
state
for
probably
the
coming
year
or
so.
B
Yeah
so
rails
changed
their
default
a
few
versions
ago.
I,
don't
remember
which
major
version
that
was
maybe
five
so
by
default.
All
of
our
primary
keys
are
eight
bytes.
Now.
A
A
There's
there's
a
few
interesting
updates
here
to
share
our
overall
goal
here
with
this
work
is
to
minimize
downtime
caused
by
large
data
migrations
and
one
one
exciting
question
we've
been
trying
to
answer-
and
this
is
just
technically
difficult-
is
like
how
long
does
a
migration
take?
So
we've
found
some
ways
to
measure
some
time
in
our
testing
scenarios
and
we're
going
to
spend
some
time
observing
for
patterns
and
really
the
the
hypothesis
here
is.
A
Can
we
see
how
our
execution
times
in
testing
maps
to
production
execution
times,
and
if
so,
then
that
allows
us
to
formulate
some
estimates
and,
if
not,
we'll,
we'll
think
about
it,
some
more
and
see
what
else
we
can
do,
but
definitely
there's
also
some
other
improvements
here.
Alex.
Maybe
you
can
touch
on
it
in
terms
of
just
the
general
parallelization
effort
that
will
help
speed
up
some
of
these
migrations.
B
Yeah,
so
for
for
both
us
and
self-managed
customers
who
are
running
these
migrations
in
the
background,
we
can
now
run
more
than
one
of
them
at
a
time
which
is
a
change
from
how
we
ran
them.
Previously,
we
used
to
run
them
all
sequentially,
so
now
you're
we're.
We
haven't
been
able
to
parallelize
within
the
single
migrations
themselves.
Unfortunately,
because
of
the
way
it
iterates
over
the
table,
it
uses
a
sliding
window.
B
So
in
order
to
make
sure
we're
not
running
a
migration
twice,
we
can't
do
the
same
kind
of
parallelization
that
we
did
with
other
migrations,
but
rather
we
are
able
to
run
more
than
one
migration
at
a
time.
So
we
started
off
with
just
two
and
I
think
we're
I
think
the
plan
is
to
go
to
Six
and
we're
working
on
making
that
configurable.
So
if
we
need
to
up
raise
or
lower
that
limit,
we
can.
A
Yeah,
so
that's
definitely
something
super
exciting
and
we're
hoping
it's
going
to
deliver
real
value
for
some
of
these
running
migrations
to
to
see
some
real
improvements
in
speed.
The
next
theme
up
here
again
A
continuing
on
theme,
is
automated
database
testing,
I.
Think
for
a
long
time,
gitlab
has
been
working
to
improve
our
database
testing
and
the
core
question
we
want
to
answer
here
is
when
a
merge
request
is
created.
A
What
kinds
of
new
queries
does
it
introduce
into
our
system
and
are
those
queries
performance?
So
one
really
exciting
progress.
Update
here
to
share
is
we
have
prototype
to
query
Interceptor,
which
basically
allows
us
to
build
a
rails
and
postgres
agnostic
solution.
A
Now,
of
course,
for
now,
we
are
primarily
focused
on
helping
gitlab
scale
and
making
sure
that
the
queries
we
introduce
are
stable
and
consistent
and
scalable,
but
the
existence
of
this
query-
Interceptor
architectural
bottle
basically
tells
us
that
you
know
we
have
optionality
if
we
want
to
try
to
build
this
a
different
way.
So
one
of
the
things
we're
going
to
come
up
here
is
to
really
focus
on
an
architecture
blueprint
for
how
we
want
to
move
forward
and
develop.
Some
of
this
work.
B
Yeah,
you
know:
we've
we've
taken
a
lot
of
time
on
this
topic
over
the
last
three
milestones
and
we've
been
bogged
down
in
a
bunch
of
different
ways
and
as
a
team
just
the
end.
Some
of
the
engineers
and
I
talked
about
this
together
and
Roger
and
I
talked
about
this
together
and
we
decided
it
was
better
for
us
to
take
a
step
back
and
just
look
at
the
big
picture
and
figure
out
what
a
path
forward
is
going
to
look
like
leveraging.
Both
this
query,
Interceptor
and
any
other
Integrations.
B
Yeah,
so
of
not
only
it,
this
comes
a
lot
out
of
our
support
requests.
So
one
of
the
number
one
reasons
that
people
have
troubles
with
migrations
is
because
their
schema
doesn't
match
what
our
expected
schema
is
checked
into
the
gitlab
repo
and
in
fact,
gitlab.com
has
the
same
issue.
We
have
a
few
tables
that
don't
match
how
the
schema
looks
in
the
in
the
repository.
B
So
what
we're
hoping
to
do
is
use
these
tools
not
just
for
ourselves
but
to
help
identify
themes
among
our
customers
so
that
we
can
identify
the
biggest
problems
and
solve
them
so
that
we
we
can
reduce
some
of
that
support
volume
and
free
up
our
support
people
to
work
on
other
important
tasks
like
helping
people
solve
other
bugs
right.
So.
A
Yeah,
that's
that's,
definitely
a
super
good
point,
and
so
now
that
brings
us
to
two
high
severity,
focused
items
and
again
items
that
we've
been
working
on
for
some
time
now.
The
first
here
is
just
removing
old
migrations.
A
This
is
something
that
gitlab
does
frequently
with
every
major
release
cycle
and
we
are
probably
about
one
third
of
the
way
through
our
current
workflow
and
we'll
continue
with
some
of
that
and
then
the
last
item
here
is
CI
partitioning
support
and
again
this
is
quite
a
bit
of
an
ongoing
problem
that
we've
been
working
through
just
for
contacts
you
know
our
Target
table
size
for
partitioning
is
10
gigabytes.
A
Our
CI
tables
are
over
one
terabyte
in
size,
so
we
we've
got
quite
a
bit
of
work
ahead
of
us
and
currently
there
are
six
total
tables
we're
focused
on
and
in
the
last
chat
Alex.
You
and
I
talked
about
zero
with
partitioning
for
viewers
and
what
that
means,
and
so
so
far
we've
done
that
on
the
easiest
table,
we've
taken
some
lessons
that
we've
learned
and
we're
going
to
apply
it
to
CI,
builds
table
next
and
sort
of
chip
away
at
it
in
there
is
there.
B
Yeah,
you
know
we
really
hoped
we'd
get.
The
CI
builds
table
partitioned
in
159
for
for
its
zeroth
partition
and
we
didn't
make
it
quite
there
and
I
just
want
to
add
some
context
around
that
it's
it's
a
much
more
complicated
table.
For
one
thing,
it
required
us
to
break
any
last
lingering
postgres
11
support
because
it
requires
partition
foreign
Keys.
The
other
thing
that
it
it
has
that
the
other
table
didn't
is
just
a
lot
of
indexes
and
a
lot
of
other
tables
referencing
it.
B
So
we've
had
to
make
a
lot
of
changes
around
being
able
to
add
the
serith
partition
that
I
don't
think
we
quite
had
the
full
grasp
of
when
we
started,
but
it's
gonna
make
partitioning
large
tables
like
this,
a
lot
easier
going
forward,
because
we'll
build
a
lot
of
these
tools
and
have
them
in
place
so.