►
From YouTube: 2020 09 01 Database Team Meeting
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
All
right
welcome
everybody
to
the
database
team
weekly
meeting
jump
right
into
it
listed
a
couple
new
items
that
came
out
this
week,
so
excuse
me,
see,
restore
from
backup
fails
due
to
irreversible
order.
Air.
It
looks
like
stands
on
that
one
and
then
andreas
looks
like
you
added
the
second
one.
B
Yeah,
but
we're
still
fighting
on
some
installations
with
installing
extensions,
which
is
mostly
a
problem
due
to
privileges,
so
you've
got
to
have
a
super
user:
how
to
do
that
and
for
installations
with
an
external
postgres
like
that
is
also
the
case:
git
labcom.
This
has
to
be
done
manually
and
I'm
adding
more
documentation
and
a
warning
message
that
is
more
verbose.
B
Hopefully,
that
helps
to
at
least
understand
what
is
going
on
when
you
run
into
that
yeah.
B
A
Let's
see
and
then
I
went
back
and
copied
goals
from
last
week,
so
we
went
through
and
marked
deliverables.
That's
done.
We
marked
all
the
issues
as
deliverable
for
this
milestone
and
then
we're
looking
at
container
registry
database
alternatives
to
share
with
haley
and
that
meeting's
happening
at
30
minutes
past
the
hour
right.
So
we
have
25
minutes
till
that
one
starts.
A
I
think
we'll
be
done
long
before
that,
let's
see
other
events
just
this
was
just
to
create
the
issue
to
formulate
the
plan
for
swapping
the
tables
after
the
ux
work
was
done.
Was
there
anything
I
missed
on
goals
we
were
trying
to
accomplish
from
last
week.
A
This
was
all
that
was
in
the
agenda
from
last
week
right
goals
for
this
week,
so
I
was
asked
about
progress
of
audit
events,
because
our
epic
has
not
been
updated
or
issues
in
epic
have
not
been
updated
and
we
didn't
have
a
description
in
the
epic.
A
A
Okay,
does
it
still,
I
know
that's
listed
as
backlog.
Another
team
owns
it.
I
believe
they
are
working
on
it
right
now.
If
they
get
done.
I
guess
it's
a
matter
of
timing.
I'm
answering
my
own
questions.
Does
it
feel
realistic
to
get
everything
else
done
in
13
4?
If
we
get
a
realistic
timing
on
the
ui
changes?
B
Either
I
mean
we're,
probably
not
going
to
swap
the
table,
but
we
will
have
sort
of.
I
think
the
goal
was
to
have
a
strategy
formulated
how
we
will
how
we
can
swap
the
table
once
the
ux
changes
are
in
and
then
we
should
be
able
to
send
the
background
migration
to
cleanup.
That
would
be
great
in
this
milestone,
and
then
we
have
like
metrics,
which
is
mostly
dominance
in
review
and
documentation
right.
B
A
B
Yeah,
so
we
we've
started
to,
or
we've
actually
sketched
a
an
alternative
database
model
and
we're
now
sort
of
running
this
by
haley,
who
knows
much
more
about
the
registry
than
we
do
and
sort
of
getting
that
getting
feedback
on
that?
We
already
bounced
a
couple
of
questions
back
and
forth,
but
this
is
like
yeah
just
an
opportunity
to
discuss
that
more,
and
the
question
is
really
is
like
those
are
like
there's
a
fundamental
difference
with
regard
to
how
we
would
implement
garbage
collection,
which
is
yeah.
This
is
the
original
motivation.
B
Why
we're
spending
time
on
container
registry
anyways
like
this
is
the
most
important
point,
and
the
alternative
database
model
would
approach
that
quite
differently.
That
is.
That
is
my
impression,
and
I
think
one
of
the
goals
for
today
is
that
we
figure
out
if
that
is
something
that
we
want
to
go
forward
with
from
a
database
perspective,
I
think
there
is
a
lot
of
benefits
to
have
from
the
from
the
alternative
model
compared
to
the
original
one,
but
yeah.
B
It
also
needs
some
thinking
about
what
is
the
overall
strategy
with
regard
to
the
garbage
collection,
how
we
implement
that-
and
I
hope
to
get
feedback
on
this
today
and
then
we
have
like
a
lot
of
follow-up
questions.
If
we
go
for
the
alternative
model
that
is
figuring
out,
what
the
all
the
details
are,
what
the
container
registry
needs
and
if
we
match
all
that
with
the
model
anything
I
forgot
janus.
D
C
Assumptions
and
some
pending
questions
and
whether
this
design
follows
the
apis
and
the
api
calls
and
the
flows
that
are
used
in
normal
registers.
So,
for
example,
so
some
things
like
what
we
are
proposing
for
live
garbage
collection.
C
C
B
And
then,
from
an
organizational
perspective,
the
question
is
like:
how
do
we
move
this
forward
like
who's
who's
driving
this,
and
how
do
we
team
up
with
the
container
registry
team?
I
think
you're
always
going
to
be
back
next
week.
B
But
they
they
obviously
know
much
more
about
the
the
container
registry
in
channels
than
we
do
so
we
totally
have
to
team
up
on
that.
I
think.
A
It
just
we're
making
suggestions
a
better
support
partitioning,
so
I
I
think
if
they
agree
upon
the
database
design,
they
can
probably
take
it
from
there,
but
that's
a
good
call
out
to
make
sure
that's
clear
once
once
this
meeting's
done
or
series
of
meetings,
I
can't
imagine
it'll
all
be
resolved
in
one
meeting,
but
once
the
discussions
have
taken
place
they
should
be
able
to
handle
it,
but
yeah
follow
up
on
that
all
right.
A
A
couple
other
items
that
are
in
our
backlog.
I
figured
I'd
check
up
on.
So
we
have
the
performance
indicator
work
that
giannis
is
working
on
learning.
Do
you
have
any
bandwidth
or
any
goals
for
this
week
to
work
on
that
giannis.
C
Yeah,
I
I
I
want
to
have
it
done
by
this
week,
but
I'm
trying
to
you
know
balance
the
various
issues
but
yeah.
Hopefully
it
will
be
done
most
of
the
code.
B
C
There
are
painting
some
tests
for
from
my
end
and
I
will
send
it
for
review
and
then
I
will
also
send
another,
mr
for
the
telemetry,
so
that
we
start
gathering
the
results
and
we
will
be
done
so.
This
should
be
definitely
in
30.4.
C
B
C
A
Awesome
all
right,
thanks
and
andreas
looks
like
you
pulled
in
the
workload
analysis
into
13-4.
Are
you
gonna
give
any
goals
for
this
week.
B
Depends
on
how
the
rest
goes
for
now,
it's
a
side
task.
For
this
week
I
was
gonna.
B
I
want
to
do
two
things.
Basically,
one
is
basically
getting
getting
a
pg
battery
report
for
all
the
locks
that
we
currently
have
so
for
one
week,
maybe
from
the
primary
and
the
second
is
basically
doing
the
same
thing
as
postgas
checkup,
but
doing
that
in
a
more
extended
period.
B
So
I
think
those
because
checkup
captures
30
minutes,
which
is
the
segments,
and
I
wanted
to
see
how
far
I
can
get
with
extending
that
to
maybe
24
hours
or
so
and
then
see
what
what
conclusions
we
can
get
from
that
yeah.
But
it's
for
now.
It's
still
a
slight
task.
I
want
to
finish
up
the
container
registry.
First,
okay,.
A
D
Let's
start
with
the
pg
repack
is
like
when
I'm
coming
back
now
from
two
weeks
of
time
off
and
I
didn't
see
any
progress
on
that
and
our
data
is
over
8.5
terabytes
at
the
moment,
I'm
a
bit
concerned
and
I'm
trying
to
emphasize
for
the
execution
going
from
the
smallest
objects
to
the
large
ones
that
are
bloated
to
avoid
any
kind
of
problems.
D
B
I
think
they,
what
we're
coming
from
with
thinking
about
moving
that
repack
or
that
reindexing
into
the
application,
is
also
that
we
we
would
be
able
to
do
this
more
frequently
than
than
we
are
at
the
moment
and.
D
B
I
think
I
I
asked
when
you
were
out
on
vacation.
I
asked
if
there
are
plans
to
sort
of
automate
the
repacking
so
that
this
happens
more
frequently
automatically,
but
I
didn't
hear
or
we
didn't,
we
don't
seem
to
have
plans
to
do
that
right,
so
it
would
for
the
moment
it's
still
a
manual
action
to
run.
The
repacking
is
that
right?
Yes,.
D
We
have
some
idea.
Yes,
we
have
ideas
like
some
issue.
That
is
some
issue
written
with
some
ideas
on
that,
but
I
agree
that,
if
we
do
it,
application
would
be
good
from
the
other
side.
I
remember
in
some
issue
that
I
wrote
some
idea
or
some
some
concerns
in
e
coli
as
well
about
like,
if
we
are
treating,
if
you
like
doing
automatically
automatically,
are
we
doing
just
indexes
or
are
we
doing
tables
and
taking
care
of
primary
keys,
or
how
are
you
approaching
this
at
the
moment.
B
B
Just
fine
from
the
application
side,
it
would
just
be
regular
indexes
for
now,
so
no
primary
key
indexes
no
tables,
but
for
the
in
the
explode.
This
is
like
90
of
the
problem,
because,
typically
you
don't
have
to
bloat
in
the
primary
keys
anyways.
D
A
B
I
think
we
would
have
to
do
the
manual
repacking
that
is
already
scheduled
at
least
anyways
like
jose
just
said,
like
it's
becoming
more
of
a
problem
at
the
moment,
I
guess
so
that
would
be
what
we're
working
on
on
the
application
side
is
more
of
a
midterm
solution
to
automating
this
okay.
A
D
E
Well,
so
it
sounds
like
still:
we
want
to
automate
it.
That's
the
decision
we
have,
but
are
we
still
debating
the
solution
on
automating?
It
I
mean,
should
we
use,
did
you
repack
or
we
want
to
do
it
in
the
application
code
seems
like?
Maybe
we
don't
have
a
decision
there
yet
or
do.
B
We
yeah
so
the
what
we
would
do
on
the
application
side
is
not
use
pg
repack,
but
rather
implement
the
manual
re-indexing
using
using
plain
sql
segments.
So
no
no
repack.
E
D
E
E
Yeah,
it's
going
to
be
yeah;
it
just
creates
the
new
index.
Concurrently
with
you
know,
temporary
name,
swaps
them
and
then
removes
the
old
one.