►
From YouTube: 2020 06 15 Database Team Weekly
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
Right
so
Jose's
been
invited
and
use
here
with
us,
so
we
have
our
SRU
counterplay.
It
will
be
with
this
on
the
other
basis.
So
thanks
for
joining
was
a
good
to
have
you
and
then
let's
jump
right
into
it,
so
we
had
goals
from
last
week.
So
the
stretch
goals,
I,
was
get
partition,
tables
and
productions.
When
you
start
comparing.
C
Yeah,
this
came
out
of
a
discussion.
I
think
we
had
last
week
where
we
realized
that
we
gotta
have
a
neat
means
to
manage
partitions,
BurgerTime
space
partitioning
and
if
we
would
just
ship
it
like
it
is
at
the
moment,
then
there
is
a
risk
for
customers
that
are
not
going
to
upgrade
beyond
the
current
release,
but
this
is
sort
of
hitting
hitting
the
wall
because
we're
not
automatically
creating
partitions.
A
C
D
C
We
generated
the
data
set
for
four
years
and
just
came
back
from
running
the
benchmark
over
the
weekend.
The
numbers
are
pretty
large
for
the
execution
time,
so
that
benchmark
takes
a
pretty
long
time
to
execute
even
further.
Only
couple
of
transactions.
There's
an
assertion
you've
been
looking
into
that
more,
but
I
think
there's
quite
a
quite
a
bit
protection
improving
that
a
lot
of
partitions-
and
maybe
indexes,
are
missing
and
stuff
like
that.
So
we
might
might
have
bit
more
more
if
she's
coming
out
all
that
yeah.
E
To
be
news
in
this
long-running
series
long-running
migrations
to
get
there's
a
problem
where
it's
still
running,
and
so
it
applies
like
another
update
or
so
just
for
exam
and
say
when
we
introduced
this
and
the
migration
starts,
but
say
there
actually
you're
like
three
or
four
versions
behind,
and
so
they
want
to
go
to
13.4.
And
so
they
kind
of
apply
these
in
relatively
quick
succession
and
don't
wait
necessarily
for
the
migrations
to
complete.
D
Mean
that
would
certainly
be
a
problem
with
the
partitioning
helpers
that
we've
been
working
on.
That's
something
we
sort
of
identified
as
a
limitation
already
that
we
can't
modify
for
partitioning
on
it
events
we
can't
modify
that
table
until
the
migration
is
complete,
something
that's
yeah
I
mean
for
this
self-manage.
That's
a
coordination
problem
that
we'll
pray,
I
think
about
a
little
bit
more
Oh
gotcha.
D
I
mean
it
work,
you
can,
you
know
the
table
functions
as
normally.
We
just
can't
structurally
modify
it,
because
that
will
break
that
migration
and
won't
be
able
to
kind
of
copy
the
data
into
the
new
table.
At
that
point,
we
can't
we
don't
really
have
a
good
solution
for
that
there
does
unknown
if
it
really
will
be
a
good
solution
for
that,
we
might
mean
to
make
the
migration
helpers
like
more
aware
of
other
changes
that
might
impact
the
data
base
so
that
they
can
kind
of
safely.
E
We
have
it
I
I,
don't
want
a
solution,
call
here
too
much,
but
could
we?
This
is
actually
different
problem.
That
I
was
thinking
of
so
I
became
up
by
this
in
a
little
bit
here,
but
there's
an
option
where
we
have
like
create
the
tip
like
the
new
person
table,
and
then
we
start
sending
new
a
lot
of
events
there
and
then
have
like
a
helper
which
then
like
lazily,
just
moves
all
the
old
stuff
over
I
don't
know,
but
you
all
would
know
more
than
I
do
there.
E
But
my
main
question
was
in
the
past:
we
had
a
bad
bad
migration
at
some
point:
I'm,
sorry
to
call
correctly
that
well
not
bad
migration,
but
there's
a
migration
at
some
point
in
time
where
it
took
a
long
time
to
complete
and
he
updated
to
a
newer
version
of
gitlab
before
it
completed
like
gitlab
crashed
because
I
think,
like
the
new
code
was
assuming
that
the
migration
was
done,
and
so
you
update
to
the
new
code
and
then
bad
things
happened.
I,
don't
recall
the
exact
issue
or
colleges.
E
C
F
C
E
It
sounds
like
we
in
the
first
case
covered
what
you
mentioned
or
we're
working
on
it
or
we're
thinking
about
it.
So
I
think
that
that
sounds
good,
which
is
the
fact
that,
like
whether
or
not
we
can
do
our
own
events
while
we're
migrating
the
content,
the
other
one
may
or
may
not
be
a
problem.
It
sounds
like
you
know:
I
went
an
issue,
I,
don't
know
if
it's
something
unique
or
not,
but
it's
not
like.
If
we
do
the
black
migration,
then
do
we
do
the
next
release.
C
B
C
E
D
A
C
A
A
D
Yeah
I
hope,
I
hope
so
I
need
to
follow
up
and
then
that's
kind
of
my
fault.
I
had
been
working
on
other
things
that
took
that
sidetrack
that
but
yeah
I'm
gonna
try
to
get
that
merged
in
okay.
D
B
B
A
C
C
C
A
That's
great
so
yeah
bündchen,
you
mentioned
you'll,
take
a
look
at
the
backlog
to
see
what
to
work
on
next,
so
finding
issues
out
there
we
missed
anything,
please
feel
free
to
add
it.
I
think
partitioning
onto
the
best
table
is
our
highest
priority
and
then
there's
some
other
issues
listed
in
there.
A
A
But
if
they're
just
gathering
so
take
a
look
afterwards,
one
thing
I
wanted
to
know
was
that
I
added
the
tools
that
we've
created
to
our
periscope,
so
it
actually
starts
accounting
for
those.
Mrs
last
time
I
looked
at
this,
we
only
have
two
for
the
month,
maybe
I
just
didn't
refresh,
but
it's
picking
up
the
partitioning
tools
project
in
our
data
base.
Namespace
now
our
database
project
so
we'll
actually
start
getting
visible
credit
for
those
at
Mars,
as
we
continue
to
work
on
them
and
you're
curious
how
to
do
that.