►
From YouTube: 2022-06-06 Database Scalability WG 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
So
yeah,
let's
get
started
it's
monday
june
6th.
This
is
the
database.
Scalability
working
group
weekly
meeting
looks
like
I
have
the
first
couple
agenda
items,
just
more
fyis
and
updates.
So
first
one
is
that
we
publicly
announced
the
downtime
window
for
the
decomposition
rollout.
A
A
Second,
next
update
is
that
dylan
just
made
an
update
to
the
phase
7
timeline
with
some
additional
staging
and
integration
test,
runs
and
links
to
those
change,
requests
and
issues.
So
right
now
we're
planning
the
final
staging
rollout.
So
that's
executing
the
decomposition
without
testing
without
testing
the
rollback
and
just
leaving
it
like
that
in
staging
that's
currently
scheduled
for
june
14th.
A
So
next
want
to
say
tuesday,
no
wednesday
next
wednesday
and
camille,
you
have
the
next
items.
B
So
it
appears
like
this
is
everything
complete
as
of
this
moment
under
something
new
pop-ups,
and
you
ask
about
like
the
the
next
plan.
I
think
we,
we
kind
of
started
thinking
today
about
a
next
phase,
that
we
may
introduce
space
8,
which
is
actually
remove
the
ci
data
from
main
cluster,
to
remove
to
like
to
relieve
the
storage,
which
is
becoming
a
concern
in
looking
at
our
saturation
metrics.
B
So
unless
they're
gonna
be
something
cars
and
popping
up,
it
seems
unlikely,
given
how
many
tries
we
had
on
staging
we're.
Gonna
be
focusing
now
on
probably
two
paths:
first,
like
truncating
data,
second
path,
figuring
out
how
to
handle
on-premise
installation.
So,
like
start
to
think
about
that
this,
this
is
gonna,
be
the
development
focus.
A
Yeah,
that's
that's
a
great
update.
Thank
you
yeah.
It's
reassuring
to
know
that
we've
we've
finished
all
the
development
work
well
ahead
of
the
scheduled
rollout,
so
yeah
that
I
think
that
makes
sense
where
the
development
team
is
still
pretty
heavily
focused
on
supporting
infrastructure
in
the
various
testing
and
rollout
steps.
So
not
quite
looking
ahead,
not
starting
that
work
yet,
but
yeah.
I
think
looking
ahead
makes
sense
and
thinking
about.
A
What's
beyond
that
and
I
did
yeah,
there
was
some
discussion
about
saturation
and
when
we
want
to
actually
remove
the
data-
and
I
link
that
in
in
your
point
below
camille,
so
yeah
thanks
for
that
update.
B
I
I
posted
another
comment,
because
there
was
like
a
question
loading
around
like
about
the
benefit
when
we
were
working
on
the
blog
post,
and
this
is
like
the
some
preliminary
results
like
take
it
like
with
pretty
big
grain
of
salt,
because
of
like
the
way
how
we
measure
that,
so
the
preliminary
results
shows
that
we
like
it
depending
on
the
time
of
the
day
we
see
like
bigger
cpu
connection,
benefit
around
the
rush
hours,
where
there's
like
significantly
more
ci
pipelines
being
created,
which
seems
to
be
like
much
closer
to
40
45.
B
Even
but
on
average,
it
seems
like
like,
depending
on
the
data
that
you
look,
there
is
like
a
link
to
slack.
This
benefit
is
like
somewhere
between
on
average
30
to
35
percent
but
like,
as
I
said,
take
it
like
with
some
grain
of
salt,
because
of
the
way
how
it's
being
calculated
for
sure,
like
the
storage
benefit,
is
like
35
percent,
we're
not
gonna
remove
more
than
ci
tables.
So
this
is
what
we're
gonna
be
looking
at.
B
We're
gonna
definitely
remove
a
significant
amount
of
the
connections
from
the
primary
and
like
it
really,
depending
on
time
of
the
day
in
the
russia
is
like
closer
to
40
and
over
40
percent.
So
it's
gonna
leave
a
quiet
amount
of
the
headroom
if
we
have
to
spin
up
new
front
end
notes
or
side
keynotes
and
I'm
kind
of
like
curious
and
like
we
started
discussing
that
because
initially
we're
estimating
more
closer
to
40
50
percent.
B
But
since
this
is
like
a
moving
target-
and
I
know
there
was
like
a
lot
of
work
on
the
ci
front-
to
make
cr
more
efficient,
this
may
be
like
an
indicator
that
ci
impact
relatively
to
everything
else.
Either
stayed
the
same
or
just
simply
got
better
over
over
this
like
one
year
that
this
project
took
time.
B
So
this
is
something
that
we
like
to
retrospect
later
like
how
how
this
change
over
time.
But
this
this
are
the
numbers
as
of
this
moment,.
A
Awesome
yeah
thanks
for
thanks
for
coming
up
with
those
estimates,
and
I
agree,
I
think
that's
a
good
point.
We
should
make
sure,
even
as
we
close
out
the
working
group
and
make
sure
that
we're
that
that
we
have
some
way
to
remind
ourselves
to
check
in
and,
like
you
said
retrospect
on
on
this
and
make
sure
that
we've
yeah
over
time
have
are
quantifying
the
benefits
from
this
project
that
you
can
see
that
informing.
A
You
know
whether
we
might
want
to
consider
decomposing
other
other
tables
versus
other
methods
to
make
them
more
efficient,
so
cool
and
then
yeah.
Last
item
jerry.
B
B
I
I
I'm
gonna
link
you
maybe
or
maybe
we
should
ask
fabian,
because
I
know
that
we
discuss
about
having
yeah
specifically
for
the.
I
don't
know.
C
A
Ux
designer
for
geo
and
distribution
made
the
made
all
the
different
enablement
team
ones
like
geo
has
one
and
database
and
memory,
so
maybe
she
can
help
but
yeah
I'll
I'll
add
it
to
the
exit
criteria.
I
think
I
think
it's
important
to
you
know
close
out
the
the
group
with
something
I'm
I'm
envisioning
like.
I
helped
to
decompose
the
the
main
database
and
all
I
got
was
this
stupid
t-shirt
type
of
logo.
C
A
It
sounds
like
we
need
an
issue
to
to
discuss
the
ideas.
Maybe
the
the
most
difficult
issue
of
this
effort
is:
is
the
t-shirt
design.
A
Awesome
all
right
looks
like
we're
at
the
end
of
the
agenda.
Anything
else
for
discussion.