►
From YouTube: 2020 05 04 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).
B
A
Right
yeah
Josh
has
everything
in
Pat's,
I
hear
so
good
call
and
pressing
the
record
button.
I
forgot
now
we're
recording
all
right,
so
Mr
total
for
April
was
seven,
so
might
be
a
good
idea
to
work
on
that
for
an
OPR
for
q2
talked
about
it
before
there's
an
iteration
training
template
out
there
Yanis
already
signed
up
for
it.
A
Thank
you,
you
honest,
and
we
can
exercise
one
of
the
steps
in
there
where
we
actually
pulling
some
examples
of
issues
that
we
worked
on
throughout
the
quarter
and
talked
about
how
we
could
have
iterated
on
then
broke
booking
them
down
and
with
the
ultimate
goal
of
increasing
our
throughput.
So
I
will
I
will
add
that
to
our
draft
for
okay,
ours,
and
we
can
talk
about
it
later
on
this
week.
A
C
A
It's
the
there's,
a
label
called
deliverable
and
it's
it's
typically
used
more
with
feature
teams
right
when
they
are
committing
to
you're
trying
to
release
a
feature
within
a
milestone
and
sadly,
with
the
database
team
lot
of
the
issues
we
get
our
late-breaking
and
come
in
during
the
milestone
or
are
not
very
well
broken
down.
When
we
start
the
milestone,
so
I
haven't
really
been
pushing
for
the
deliverable
use.
We
got
asked
about
it
this
last
time
there
was
a
an
issue
to
kind
of
work
on
iteration,
to
look
at
targets
for
deliverable.
A
So
much
like
everything
else.
There's
a
70%
goal
for
hitting
deliverable
targets.
We
can
label
anything
is
deliverables
which
is
fine.
It's
not
something.
We
talked
about
something
we've
trained
or
even
started
using.
So
it's
something
that
we
can
talk
about
when
we
have
that
planning
meeting
when
we
talk
about
how
we
want
to
plan
for
milestones
and
that
they
can
start
using
the
deliverable
label
in
13:1.
So
it's
not
something.
A
B
A
Let's
do
it
when
Josh
is
around
he's,
gonna
have
sure
more
details
well,
but
this
was
just
top
of
mind
thinking
when
we
were
talking
about
what
features,
what
what
our
users,
seeing
when
they're
using
get
loud
and
what's
slow
and
what
maybe
would
partitioning
and
charting
help
with.
So
these
were
just
some
of
the
access
patterns
that
came
to
mind
we're
talking
about
it.
A
Okay,
our
issue
out
there
please
provide
feedback.
I
have
a
draft
out
there.
I
was
wrong
on
the
dates.
I
thought
it
was
due
on
the
8th,
but
it
was
due
on
Friday
and
the
fact
that
we
have
an
issue
is
good
enough.
For
now
we
can
continue
to
revise
it
over
the
next
week
or
two
and
make
sure
that
we're
all
on
board
they'll
agree
with
the
goals
and
they're.
A
Specific
enough
that
we
can
actually
accomplish
them
so
take
a
look
and
we'll
continue
revise
them
over
the
next
week
or
so
and
as
I
referenced
above
during
an
office
hour
session.
Probably
maybe
a
plan
for
Thursday
I
think
tomorrow
we
need
to
talk
more
about
partitioning
and
shouting,
but
on
Thursday
we
can
talk
about
how
we
want
to
start
doing
planning,
because
there
were
a
lot
of
suggestions
that
have
flown
around
and
getting
the
team
more
involved
in
the
planning
sessions
would
be
good.
A
We
don't
have
a
full-time,
dedicated
product
manager
between
Josh
and
I,
ever
doing
the
best
that
we
can,
but
now
that
we
have
a
bigger
team,
you
all
are
chewing
through
the
backlog
faster,
and
we
need
to
make
sure
that
we're
doing
a
good
job
and
getting
specific
issues
out
there
and
came
back
from
everybody
and
which
was
the
right
things.
Work
on
that
on
Thursday
plan
for
Thursday
for
the
body
here.
B
B
A
B
B
A
Need
to
understand
how
pervasive
it
is
like
how
frequently
customers
are
running
into
this
issue
and
how
painful
the
workaround
is,
because
if
it's
infrequent
and
it
has
an
easy
workaround,
then
we
shouldn't
prioritize
it.
But
if
it
happens
a
lot
and
it's
painful
for
the
customers,
then
you
know
we
should
bring
it
in.
But
thanks
for
the
review,
do
we
have
any
data
on
how
often
this
happens
or
how
painful
the
workaround
is?
I.
B
A
So
was
there
a
specific
path?
Are
they
jumping
from
one
specific
version
to
another
that
causeth
I?
Don't
call
the
background
on
this
one,
but
it
seemed
like
it
was
an
infrequent
problem
wondering
if
documentation
would
just
help
solve
this
problem
instead
of
us
fixing
it
like
I
said:
if
it's
a
difficult
problem
to
solve,
then
we
just
mark
it
as
a
known
issue
and
provide
the
documentation
for
how
to
fix
it.
When
you
encounter
that's.
B
Probably
auction
yes,
on
the
other
hand,
we
shouldn't
have
those
inconsistencies
in
the
first
place,
so
it
might
pay
off
in
the
long
run
figuring
out
where
they
come
from,
or
have
some
guards
against
those
inconsistencies,
because
what
happens
is
basically
that
over
time,
the
schema
that
some
installations
have
this
deviates
from
from
the
schema
that
we
expect
them
to
have,
and
that's
that's
a
problem
when
you
do
late
later.
Migration
is
because
you
rely
on
the
information
that
you
have.
B
A
B
I
think
that
that
one
is
on
us,
so
we've
had
a
couple
of
points
in
the
history
where
we
introduced
inconsistencies
to
this
kima
that
we
give
out
for
new
installations
and
that
schema
is
somehow
different
than
the
one
that
existing
installations
have
yeah.
We
have
to
deal
with
that
difference,
but
at
this
point
I.
C
B
So
in
this
case
there
were
just
two
indexes
sitting
around
with
the
same
definition
and
later
later,
migration
was
trying
to
drop
one
of
them,
but
the
migration
I
helped
repels
out
as
soon
as
it's
realizes
that,
or
there
is
two
years
like
similar
induction
indexes,
which
one
do
you
want
me
to
drop
like
I,
don't
know
we
could
be
fixing
that
that
index
migration
I
hope
a
problem
I'm,
making
that
more
eager
to
drop
both
indexes.
In
that
case,
I
guess
they're
the
same.
C
B
Yeah
would
also
be
useful
to
look
at
good
luck,
for
example,
which
has
been
aware,
which
is
a
large
or
a
long-running
installation.
You
could
say
and
compare
that
to
to
the
schema
that
we
have
on
the
code
base
to
fix
any
like
inconsistencies
and
the
other
way
to
look
at
this
is.
We
should
have
tooling
in
place
that
make
sure
that
our
migration
code
is
consistent
with
the
schema
that
we
check
into
the
code
base,
because
that's
that's
where
the
problem
comes
from.
B
B
B
The
migration
itself
is
totally
fine.
We
don't
know
yet
if
that
migration
didn't
run
or
or
was
rolled
back,
or
something
like
that,
so
I've
asked
for
more
details,
but
it
doesn't
look
like
any
any
kind
of
migration
related
issue,
maybe
rather
something
that
happens
when
you,
when
you
do
an
upgrade,
and
then
there
is
an
error
for
some
unrelated
reason.
B
A
A
B
A
And
this
is
gonna
point
to
my
lack
of
knowledge
about
I,
know,
there's
a
couple
different
understanding
of
what's
gonna
actually
be
in
this
database,
but
I
think
if
you're
recommending
a
separate
database
altogether
for
this
for
the
container
registry
application,
it's
gonna
go
against
the
goal
of
having
a
single
database,
even
if
it's
in
its
own
separate
schema
right
going
against
the
goal
of
the
single
data,
store
single
application
to
support
our
sales.
So
I'm
just
wondering
why
we're
still
recommending
a
separate
database.
B
So
my
understanding
is
that
or
maybe
I
missed
an
update
on
that
or
did
the
final
conclusion
that
so
maybe
that's
the
case
here,
but
my
understanding
was
that
you
basically
reached
the
point
where
we
said
that
we
recommend
using
separate
databases.
So
we
don't
want
multiple
applications
use
the
same
logical
database
for
good
reasons,
and
if
we
wanted
to
have
this
data
in
the
same
database,
then
the
functionality
itself
of
sort
of
container
registry
service
that
would
also
need
to
live
in
the
rails
database.
B
A
I
think
the
request
still
stands
that
it
lives
in
the
same
database
and
I.
Think
the
the
separation
we're
talking
about
is
it
doesn't
make
sense
for
it
to
be
in
the
rails
database
as
tables
within
the
rails
database
and
managed
by
rails.
Because,
as
commented
in
this
issue
we'd,
they
basically
have
to
start
from
scratch
and
rebuild
the
whole
thing
right
and
have
it
be
an
integrated
part
of
the
rails.
App
so
I,
don't
think
anybody's
suggesting
that.
B
B
Okay,
so
maybe
maybe
we
can
do
a
quick
recap
of
of
the
terms
and
see
if
that's
that's
the
same
thing
you
think
about
that.
So
in
protocol
terminology
there
is
a
database
cluster,
that's
basically
a
group
of
database
instances
they
replicate
each
other
or
from
the
primary,
and
so
this
is
rather
the
physical
setting,
so
database
cluster
is
the
full
set
of
your
full
database.
You
run
that
on
multiple
instances.
Whatever,
then
there
is
a
database
that
is
basically
that
lives
on
a
database
cluster
right.
B
That
is
a
logical
sort
of
entity
in
a
database
cluster,
and
in
that
database
you
can
have
your
tables
basically
or
the
database
schema
for
your
application
right.
What
Postgres
also
supports
is
doing
scheme
Mouse,
so
cuscus
schemas.
They
live
inside
a
database
and
they
the
only
thing
they
do
is
group
or
act
as
a
group
mechanic
for
tables.
So
you
can
basically
group
them.
Logically,
in
the
same
database
right,
you
could
have
I,
don't
know
you
have
one
application
having
two
separate
features:
they
don't
overlap
or
whatever
you
want
to
group
tables.
B
B
B
It
also
to
cross
schema
curious.
It's
not
a
problem
yeah,
but
that's
totally
up
to
you.
What
I'm
talking
about
here
in
the
high
common
is
a
database.
So
that
is
a
logical
separation
on
the
same
cluster,
perhaps
also
a
different
cluster
that
something
that's
up
to
you
but
understand,
omnibus
and
for
would
be
same
database,
and
the
idea
is
that
you
don't
want
more
than
one
more
than
one
application
sharing
the
same
database
right
because
then
you
make
the
database
and
act
of
a
community.
C
B
B
For
example,
and
schema
management
really
is
a
pain
if
you
have
multiple
different
applications,
sort
of
trying
to
do
that
at
the
same
in
the
same
database
and
that
what
you
can
argue
is
and
that
what
popped
up
in
the
conversation
as
well
as
doing
one
database
and
having
each
application
Oh
in
their
own
schema
in
the
database.
Yes,
the
point
I'm
making
in
our
comment
is
that
that
doesn't
make
any
sense
if
there
is
no
overlap
between
those
two
schemas
and
that's
exactly
what
we
don't
want.
We
don't
want
up.
B
We
don't
want
one
application
to
talk
across
its
own
sort
of
part
of
the
database,
but
it
it
owns
a
few
tables
and
it
should
only
use
them
and
not
not
use
other
tables
owned
by
a
different
application,
and
you
don't
need
that.
There
is
no
reason
to
use
this
pattern
where
you
put
applications
into
their
own
schema,
because
there
is
no
overlap
between
schemas
in
the
first
place,
right
from.
C
A
logical
perspective,
it's
better
if
you
need
to
separate
them,
why
not
put
them
in
different
databases
so
that
you
should
keep
any
problems
any
wrong
assumptions:
databases
inside
the
database
cluster?
So
it's
the
same!
You
keep
any
assumption
that
they
reside
in
the
same
database.
So
if
you
have
to
separate
them
from
github.com,
for
example,
you.
A
A
The
request
is
for
us
to
make
it
all
work
in
one
database
and
continue
to
support
that
single
application.
Single
data
store
that
a
huge
selling
point
and
part
of
our
iacv,
and
if
we
cannot
do
that,
then
we
need
to
have
data
as
to
why
or
if
it's
gonna
be
inefficient,
problematic
cause
us
I
guess
inhibit
our
ability
to
sell
in
the
future,
because
we
have
so
many
problems
like
we
exhaust
our
connection
pool
or
you
know
whatever
other
reason,
we
need
actual
data
and
prototyped
behind
it.
Instead
of
best
practices
that
makes
sense.
A
B
Not
sure
I
mean
it's
sort
of
a
sort
of
an
architecture,
design
problem
as
well
right
and
going
back
to
my
comment,
I'm
saying
that
if
we
had
a
good
reason
to
do
the
same
database
queries
together
with
data
from
rails.
The
logical
conclusion
is,
you
know
in
the
same
database.
Logical
conclusion
is
that
we
would
have
two
good
container
registry
code
into
github
rails.
B
So
what
I'm
not
seeing
here
is
why,
if
we
don't
want-
or
if
we
really
want
a
single
database,
what
that
automatically
means
is
that
we
have
a
single
application
as
well
and
in
fact
we're
saying
single
application.
Single
data
wait.
So
why
are
we
talking
about
container
registry
being
in
separate
service
networks?
Place
that
that's
what
doesn't
make
sense
to
me?
We.
B
A
C
A
C
Point
this
is
if
this
is
a
separate
project
and
it
is
a
separate
project,
because
we
think
that
people
who
use
it
by
itself,
but
why
use
the
developer
database
so
do
people
usually
these
are
people,
go
to
use
it
on
itself
and
if
they
are,
if
they
are
not,
why
it's
not
part
of
our
code
base
and
if
it's,
if
we
have
it
as
a
separate
thing,
because
we
think
people
who
are
going
to
use
it,
maybe
our
people
are
going
to
meet
around
migration.
Forgive
them.
A
And
I
think
that's
a
product
question
they're
gonna
have
to
answer:
do
they
want
this
to
be
standalone
and
if
they
don't
doesn't
need
to
be
an
integrated
piece
of
yet
lab?
And
if
that's
the
case,
that's
didn't
need
to
be
rewritten
right,
so
I
think
there's
a
product
stakeholder.
It
needs
to
be
involved
in
that
conversation
and
the
question
you're
asking
about
it
being
a
standalone
service.
A
I
know
there's
an
answer
for
it:
I
think
it
can
be
and
if
we
bring
it
into
get
lab,
it
removes
the
ability
to
plug,
in
other
other
features
and
I
can't
remember
what
it
is.
So
are
you
under
SS
I
think
you
added
as
attempt
tentative
to
joining
the
charting
working
group?
Are
you
going
to
be
able
to
make
it?
Oh.