►
From YouTube: GitLab 13.1 Kickoff - Enablement:Database
Description
Learn more about what the Database team plans to accomplish in GitLab 13.1.
A
A
First,
we
have
up
here
our
team
board.
You
can
see
we
have
still
a
number
of
issues
open
from
13.00.
We
expect
a
number
of
these
to
be
closed.
However,
some
of
them
will
likely
carry
through.
So
we
are
planning
some
room
in
13.1
to
make
sure
we
can
finish
up
on
the
ones
that
we
don't
the
key
change
we're
making
here.
The
key
focus
area
for
the
team
is
to
implement
sharding
for
our
postgres
database,
and
so
you
can
see
we
have
an
epic
here
which
you've
been
executing
on
for
some
time.
A
We
will
be
requiring
posters
11
for
all
of
our
customers,
and
this
now
allows
us
to
go
ahead
and
take
advantage
of
partitioning
here
in
subsequent
releases,
and
so
we've
had
some
work,
laying
the
foundation
for
that,
and
now
I'm
very
excited
for
us
to
be
able
to
go
ahead
and
actually
implement
partitioning.
These
next
couple
milestones.
A
A
A
We're
also
measuring
the
baseline
performance
of
this,
because
partitioning
can
implement
some
planning,
overhead
and
so
I'll
make
sure
good
handle
on
those,
as
was
also
exploring
more
ways
to
enforce
the
partitioning
key
to
be
utilized
in
queries.
Without
it,
they
can
take
a
much
longer
time
to
complete,
and
so
this
is
the
key
things
that
things
working
on.
This
is
a
relatively
smaller
team
than
most
engineering
teams
here
at
gitlab,
and
so
it
is
a
relatively
correspondingly
smaller
set
of
issues
we're
working
on
and,
of
course,
also.
A
These
tend
to
be
some
pretty
big
hefty
things
that
we
are
working
on,
namely
doing
the
first
implementation
of
partitioning
for
our
database.
So
those
are
the
key
aspects
that
we're
working
on
this
release.
There
are
a
few
other
things
working
on
as
well,
if
you're
going
to
the
third
one
around
just
general
improvements
to
database
usage
in
gitlab
like
some
rubikoff
improvements
and
things
like
that.
A
But
again
the
key
focus
for
the
team
and
would
be
continuing
to
be
a
key
focus,
is
delivering
on
partitioning
and
sharding
to
continue
to
buy
additional
performance
and
headroom
for
our
larger
gitlab
instances.
As
well
as
also
gitlab.com,
if
you
have
questions
or
suggestions
on
how
to
implement
a
better
database
architecture
and
partitioning
if
you
experience
postgres,
come
find
us
in
these
issues,
we
would
love
the
expertise
and
knowledge
and,
of
course,
we'll
be
looking
forward
to
delivering
these
and
thirsting
that
one
and
continue
to
execute
on
the
overall
partitioning
starting
plan
going
forward.