►
From YouTube: 2020 04 27 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
Just
talk
about
what
iteration
means
to
each
of
us
maybe
get
some
example
issues
that
we've
worked
on
in
the
past
or
MRR
that
we've
worked
on
in
the
past.
That
probably
could
have
been
broken
down
a
little
further
and
just
get
a
common
I
guess
goal
agreement.
Understanding
of
what
iteration
looks
like
for
each
of
us.
A
So
look
for
an
issue
that
come
out
for
the
team
shortly
and
then
I
think
we'll
broad
just
focus
on
the
partitioning
charting
discussions
that
have
been
taking
place
over
the
last
couple
days.
There's
been
I,
don't
know
if
a
lot
of
directional
changes
is
the
right
way
to
put
it,
but
there's
just
there's
been
a
lot
of
information
and
a
lot
of
dots
that
have
been
shared
over
the
last
couple
days.
So
the
big
thing
there
were
a
couple
meetings
on
Friday
where
Sid
was
involved,
he
really
tried
to
communicate.
A
You
know
he
used
I.
Think
you
used
the
term
turbo
I
can't
remember
exactly
the
turbo
drivers
to
turbo
drivers
for
us
for
our
IC
v4
getting
customers.
The
selling
point
we've
been
using
over
the
years
is
the
single
application,
single
datastore
and
his
biggest
concern
there
about
us
going
down
the
service
extraction
route
is
that
it
negates
those
stories
right.
A
It
makes
it
much
more
complicated
for
our
self-managed
customers
when
we
start
extracting
and
the
multiple
services
have
multiple
databases
to
configure
and
in
some
of
the
subsequent
conversations
you
know,
there's
still
some
validity
to
the
ideas
about
service
extraction
and
the
way
aundrea
has
put
it.
You
know
it's
the
isolated
access
patterns
that
we
really
need
to
look
at
so
figuring
out.
A
A
way
to
I
guess
bring
those
ideas
of
service
extraction,
but
still
keep
it
into
the
single
act,
seem
single
application,
single
database
and
prototype
on
sharding
with
our
current
single
application
single
database.
So
we
can
have
some
actual
data
on
and
build
on
the
prototype.
That
andreas
is
already
published
to
our
handbook
and
figure
out
how
we
can
do
that
isolated
access
pattern
within
the
single
application,
single
database,
so
I've
said
a
lot
of
words.
A
Does
everybody
understand
the
point
I'm
trying
to
get
to
so
the
goal
is
we
are
going
to
move
forward
with
prototyping
sharding
on
our
current
infrastructure?
Our
current
architecture
bring
in
some
of
the
ideas
that
we
think
service
extraction
would
solve
for
our
scaling
solution
on
the
database
with
charting
and
partitioning
in
mind
and
still
keeping
it
a
single
application.
A
In
parallel,
the
container
registry
team
is
going
to
do
some
prototyping
and
the
things
that
we
talked
about
on
that
side
was,
you
know,
keep
the
applications
service
as
it
is,
because
I
think
portions
of
it
were
written
and
go,
and
that
still
makes
sense
to
keep
that
the
implementation
they
have
in
rails.
But
what
they're
gonna
look
at
its,
how
they
bring
the
database
piece
in
whether
it's
additional
tables
to
our
current
database,
which
is
the
ultimate
goal
or
tables
in
its
own
schema
in
our
database
or
even
prototyping?
A
B
A
Would
be
hesitant
to
answer
that
question
because
I
don't
know
enough
I
think
if
there
are
any
questions
on
the
container
registry
and
the
implementation
on
how
that's
gonna
work,
I
would
just
redirect
it
was
Dan
Croft,
but
John
Hampton
has
taken
over
I
would
start
with
Dan
in
the
package
group
and
figure
out
more
implementation
details
there,
and
actually
he
was
invited
to
the
sharding
brainstorming
session
or
I'm.
Sorry,
this
sharding
working
group
meeting,
which
is
just
after
this,
so
we
can
ask
some
more
implementation.
Details
then.
B
C
A
A
Okay,
so
as
far
as
next
steps
for
prototyping
I
don't
have
any
good
answers,
since
it's
all
kind
of
came
down
on
Friday,
it's
something
we
can
talk
about
asynchronously
and
get
some
ideas
on
what
our
approach
will
be,
and
it's
probably
gonna
be
a
lot
of
the
same
content.
We
talked
about
in
the
next
meeting,
so
I'll
put
together
an
already
exist.
D
But
in
general
it
is
enough
to
have
multiple
different
services,
internal
or
external,
accessing
the
same
database
and
a
lot
of
problems
too
from
that,
so
I
can
see
why
we
may
not
want
to
take
the
ICD
out
of
our
database,
another
container
registry.
Why
not
have
it
in
a
different
database,
even
if
it's
in
the
same
cluster.
A
D
B
D
A
We
can't
get
on
the
same
page
with
so
the
the
single
data
store
in
the
way
it's
currently
defined
is
truly
a
single
database
with
all
the
tables
in
one
where
and
how
much
the
container
registry
actually
needs
of
the
rails.
Database
is
still
unclear
to
me
because
again,
I
only
have
Friday
to
go
back
on.
A
As
far
as
my
understanding
of
what
the
container
registry
implementation
is,
there
will
be
some
functionality
built
in
to
get
lab
for
the
container
registry,
but,
as
Josh
just
said,
the
majority
of
the
work
they've
done
so
far
is
just
forking
the
existing
one,
because
it
was
no
longer
maintained.
A
lot
of
our
customers
need
some
functionality
there,
so
I'm
not
sure
how
much
of
it
will
be
built
in
to
get
lab,
but
they've
there.
There
are
pieces
of
the
container
registry
that
will
be
built
in
to
get
out,
so
they
will.
A
There
will
be
a
small
set
of
tables.
As
my
understanding,
that
will
be
a
part
of
get
lab,
and
there
was
just
some
discussion
on
how
much
of
the
actual
container
registry
functionality
needs
to
be
brought
in
or
not,
and
there
will
be
part
of
the
ongoing
discussions
as
we
work
through
these
prototypes
and
I
will
rely
on
Dan
to
make
sure
that
he
communicates
correctly
on
what
that
overlap
is
because
I,
just
I,
don't
know
at
this
point
in
time.
D
So,
if
I
cannot
recap
of
what
my
understanding
here,
if
were
back
to
focusing
partitioning
separate
babies,
our
focus
is
on
gaining
from
splitting
so
from
lowering
the
index
Isis.
But
in
reality
we
cannot
solve
those
parts
because
in
order
to
really
solve
the
database,
we
need
to
bring
everything
together.
So
in
reality,
what
we
are
discussed
at
the
moment
is
a
partition
solution
that
will
just
lower
the
size
of
indexes
and
make
accessing
the
data
out
faster.
Am
I
right.
B
Yeah
I
think
the
the
problem
that
comes
with,
that
is
that
we
have
multiple
access
patterns.
So
perhaps
that's
something
that
we
can
consider
for
a
prototype
to
show
how
to
deal
with
different
access
patterns.
As
an
example,
we
have
a
lot
of
things
that
are
inside
a
namespace,
so
you
know
if
we
partition
that
by
namespace
that's
perfect,
but
unfortunately
we
also
have
on
the
same
data.
We
also
have
perspectives
that
come
from
outside,
so
we
have
user
assignments,
for
example,
where
you
don't
have
any
namespace
key.
B
You
have
just
of
a
user
right
now.
If
we
had
a
solution
that
is
namespace
partitioning
the
user
access
pattern,
that's
not
going
to
be
great
because
you
don't
have
the
partitioning
key
in
this
case
right.
So
this
there
there
are
two
conflicting
access
paths.
Perhaps
we
can,
we
can
show
and
prototype
how
we
would
how
we
would
break
that
up
going
forward
and
I
think
this
is
where
we
brought
service
extraction
into
the
into
the
game
so
to
say
to
isolate
that
and
and
deal
with
that
separately.
B
A
And-
and
one
of
the
things
that
we
are
trying
to
get
to
is
where
we
can
actually
shard
and
farm
this
out
to
different
servers,
so
we
can
scale
horizontally
as
well.
Honestly,
I,
don't
think
that
was
I.
Don't
think
you
mentioned
that
your
recap
so
you're
the
way
I
understood
your
description
is
more
about
improving
performance,
but
it's
also
about
that
horizontal
scaling
piece.
A
So
with
partitioning
and
foreign
data
wrappers
in
Postgres,
we
can
actually
achieve
that
goal
of
the
horizontal
scalability,
but
it
does
come
at
a
cost,
as
Andreas
was
talking
about
the
cross.
Shard
joins
are
gonna,
be
painful
and
that's
part
of
the
exercise
of
this
prototype
and
isolating
access
patterns
is
understanding.
B
B
Representation
of
sharding-
this
is
one
question
and
the
other
question
that
I
find
more
interesting
for
us
is:
how
would
we
apply
that
to
get
lab,
knowing
that
this
application
is
not
chargeable
by
default
right?
We
have
so
many
different
access
patterns,
I
like
to
think
that
this
is.
This
is
the
much
more
interesting
question
for
us
to
start
with.
B
D
A
Yeah,
none
of
the
powers
we're
talking
about
are
gonna,
be
simple
and
they're
gonna
be
they're
gonna
take
awhile
and
require
some
deep
investigation,
so
it'll
be
an
interesting
problem
to
solve
I
like
the
way
that
andreas
described
it
earlier.
When
I
was
talking
to
him
about
figuring
out
and
isolating
the
access
patterns
within
the
application.
Today,
it's
still
it
still
kind
of
falls
along
the
lines
of
our
thinking
about
service
extraction,
but
within
the
guidelines
of
keeping
it
within
the
application.
So
a
good
clarification.
B
There
is
an
interesting
note
from
the
call
on
Friday,
where
sits
that,
basically
users
within
an
organization
they
only
care
about
their
organization
and
that's
why
I
could
live
itself.
The
application
lends
itself
to
charting,
because
you
know
you
can
just
sharp
by
organization.
You
don't
need
any
consider
any
any
other
organization.
I
think
that's
sort
of
behind
that.
Why
we're
discussing
namespace,
sharding
but
I,
find
interesting
in
is
that
we
don't
have
any
notion
of
an
organization
at
the
moment
and
goodlove
right.
So
we
have.
We
have
a
lot
of
users.
B
A
Yeah
so
I
think
tomorrow
during
database
office
hours,
we
can
start
I.
Guess
writing
down
issues
on
how
we
can
approach
this.
So
we
can
all
have
something
concrete
to
start
working
towards,
or
at
least
brainstorming
what
issues
you
need
to
create
because,
like
I
said,
I
know
it's
a
lot
of
information
and
directional
change.
A
A
Yeah,
probably
four
or
five
directional
major
directional
changes
in
there,
so
there's
probably
a
lot
of
content
in
there.
That's
no
longer
valid
or
actionable
on
the
direction
we're
going
now
so
yeah.
Well,
we
can
all
comment
on
that
issue
over
there
and
we
can
recap
tomorrow
or
further
work
on
it
tomorrow,
all
right
so
for
13.0.
B
E
E
E
C
A
E
It
would
be
part
of
the
research
that
we
would
do
looking
at
the
access
patterns
and
how
we
would
split
things
up
so
I
think
probably
the
best
thing
to
do
would
just
be
to
pause
this
one
yeah,
okay,
it
may
still
be
useful,
I
think
we're
really
early
in
this
stage.
You
know
whether
that's
true
or
not,
okay
and
the
other
two
that
I
have
they're
they're
both
in
review
and
got
some
feedback.
E
D
D
D
A
B
A
B
Love,
we
still
have
about
13
open
issues
in
the
milestone,
undesigned
or
maybe
not
on
this
one,
but
not
started
yet.
Perhaps
we
can
use
when
we
talk
about
prototyping
I
think
we
should
also
review
what
were
you,
what
we
have
in
the
milestone
and
what
we
you
know
push
out
or
in
favor
of
the
prototyping
yeah.