►
From YouTube: GitLab 12.6 Kickoff - Database
Description
Database Group Kickoff for the 12.6 release
A
Hi
I'm
Josh
Lambert,
a
product
manager
here
at
KITT,
lab
and
I'll,
be
walking
you
through
our
plans
for
the
12.6
milestone
for
our
database
team.
Our
database
team
is
focused
on
improving
in
general
database
performance
and
architecture
and
best
practices
for
improving
the
performance
of
gitlab,
as
well
as
improving
how
high
we
can
scale
and
finally,
also
helping
to
arm
the
butter
team,
so
they
can
work
with
our
database
more
efficiently
than
they
have
in
the
past
along
those
themes.
We
have
a
few
things
here
that
were
working
on
for
12.6.
A
First,
just
a
quick
note:
this
is
a
fairly
small
team.
We
only
have
one
engineer
currently
for
this
milestone.
We
are
hiring.
So
if
you
are
a
database
expert
and
you
join
the
team,
please
to
apply
and
as
we
grow
a
team
of
course,
we
will
to
also
grow
and
increase
our
throughput
for
milestones
in
the
future,
but
for
now
working
on
a
handful
of
very
important
things.
The
first
is
that
we're
working
to
in
general
improve
our
about
the
performance
and
reduce
the
impact
of
our
API.
A
A
This
can
really
increase
the
load
on
our
database
and
as
you
get
to
higher
and
higher
and
higher
offsets,
and
so,
as
you
get
to
like
offset
10000
for
example,
or
plus,
if
you're
trying
to
do,
for
example,
it
did
it
export
of
a
very
large
project.
This
can
really
have
a
very
high
impact
on
the
gate
lab
server.
What
we
will
be
doing
is,
we
will
be
limiting
offset
based
pagination
in
a
future
milestone
to
10,000
records
by
default.
A
Endpoint
right
now,
that's
one
of
our
heaviest
endpoints
and
we
see
a
lot
of
traffic
to
it.
And
so
this
will
help
to
really
reduce
the
impact
and
get
lab
service,
while
still
providing
a
method
for
those
exhaustive
sets
of
retrieving
a
data.
So
that
is
the
first
one
here
and
until
that
six
will
be
looking
to
add
improve
support,
we're
just
about
done
with
the
initial
key
set
based
pagination
until
about
five
there's,
a
small
chance.
A
Moving
on
to
a
couple
other
areas,
we'll
also
be
looking
to
evaluate
how
you
can
potentially
do
sticky
read,
load
balancing
the
idea
here
is
that
currently
we
randomly
distribute
read
across
all
replicas.
The
problem
here
is
that,
on
larger
instances,
this
effectively
doesn't
take
advantage
of
the
fact
that
you
have
n
different
caches
out
on
those
different
replicas
and
you're,
essentially
trying
to
have
them
optimized
for
their
caches
for
the
entire
scope
of
database.
A
While
we
still
work
to
drive
towards
partitioning
as
well
on
the
topic
of
partitioning
we're
working
on
a
couple
major
items
here.
The
first
is
that
we've
decided
to
accelerate
our
support
for
Postgres
eleven.
This
announcement
will
be
going
out
in
the
11.5
release
post
and
the
plan
will
be
to
effectively
aim
to
have
posters
11
as
the
minimum
required
version
in
13.0.
A
A
If
we
don't
make
pd
11
the
minimum
required
default,
then
we
can't
really
leverage
the
new
features
in
Postgres,
because
we
really
don't
want
to
have
to
have
multiple
code
pass
for
different
versions
of
Postgres,
and
so
the
idea
here
is
that
will
set
PG
11
as
the
new
floor
and
from
there
we
can
stay
on
a
more
recent
cycle.
The
idea
being
is
that
PG
11
will
be
minimally
required
and
get
lab
13
and
then
and
get
up.
A
14
PG
12
will
then
become
the
minimum
required
version
and
will
essentially
be
staying
a
year
off
of
the
Postgres
Ely
upgrade
cycle
with
the
gitlab
nearly
upgrade
cycle,
and
that
will
be
staying
reasonably
within
sync.
On
a
well
maintained,
well
tested
version
of
Postgres
going
forward,
but
we
have
to
kind
of
do
as
accelerated
catch-up
phase
here
in
the
interim
and
so
we'll
be
doing
some
work
here
on
both
distribution
and
database
to
get
this
done.
The
main
item
here
from
the.
A
Next
up
we'll
be
doing
some
optimizations
to
to
get
Lacombe
database
first,
we'll
be
checking
to
see
if
there
are
any
unused
indexes
and
we
can
then
potentially
drop
these
and
then
we'll
also
be
working
to
improve
our
tooling
and
documentation
to
identify
how
to
safely
drop
database
columns
from
our
database,
and
so
these
are
things-
are
ongoing
grooming
and
maintenance
of
our
database
to
help
ensure
we
have
don't
have
any
kind
of
croft
lying
around.
So
that's
the
topics
here
for
the
2006
release
of
database.
A
If
you
have
any
questions,
you
know
where
to
find
us
here
comment
on
these
issues.
You
can
find
them
at
using
the
label
group
database
and
then
I'll,
stone,
12.6
and
we'd
love
to
hear
from
you
and,
of
course,
we'll
keep
you
updated
as
far
as
future
updates
here
on
the
same
YouTube,
unfiltered
channel
of
gitlab.
Thank
you
very
much.