►
From YouTube: 2022-07-05 DB Scalability Working Group 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
B
All
right,
let's
get
started
yeah.
I
guess
we'll
start
with
the.
The
big
news
is
that
a
thing
happened
this
weekend
and-
and
it
went
pretty
well
so
yeah,
just
a
huge,
huge
congrats
and
thanks
everyone
who
is
involved
in
the
decomposition
over
the
last
decomposition
effort
over
the
last
year.
Lots
of
lots
of
thanks
and
celebration
shared
in
a
lot
of
different
channels.
B
So
just
yeah
great
to
see
great
to
see
us
get
to
that
point,
and
I
linked
to
the
ci
decomposition
retro
issue
that
dylan
opened
so
yeah,
please,
everyone
feel
free
to
chime
in
there
with
thoughts
and
comments.
I
think
a
lot
a
lot
of
good
takeaways
for
for
future
big
maintenance
efforts
like
this.
B
C
I
I
kind
of
expect
to
rather
wait
a
full
week
to
assess
application
performance,
but
there
is
a
few
interesting
out
of
the
database
behavior
that
you
can
look
in
this
issue.
Maybe
I
could
share
my
screen
and
spend
like
two
minutes
discussing
that
there
is
clearly
some
like
not
disabled.
Observations,
for
example,
like
number
of
used
right
table
connections
on
on
the
on
the
patrony
of
main.
C
C
So
it
kind
of
it
seems
to
indicate
that
ci
is
rather
like
a
long-running
transaction
type
of
the
workload
where,
on
the
main,
we
rather
have
quite
the
amount
of
the
helm
on
the
connections,
but
they
are
mostly
like
very
short
transactions
to
execute
that
doesn't
really
hog
the
database
for
too
long
like
the
the
monday
yesterday
was
like
pretty
strange
because
of
the
us
holiday,
but
I
think
the
same
pattern
kind
of
follows
two
days,
so
we
can
assume
that
this
peaks,
like
if
you
sum
like
200
with
160
kind
of
gives
you
like
the
peaks
from
the
last
week,
so
it
seems
to
be
like
rather
a
new
normal
behavior,
of
how
many
connections
we
need
on
the
main
seconds
like
cpu
loads,
it's
kind
of
mixed
back,
because,
depending
on
time
of
the
day,
we
observe
something
like
a
reduction
from
50
to
25
or
like
from
from
like
the
peak
here
is
like
a
peak
of
60
of
the
or
maybe
I'm
just
gonna
enlarge
that
here
like
there
are
like
peaks
of
60
percent.
C
But
these
are
rather
like
a
peaks.
Oh
sorry,
I
clicked
the
wrong
teammates,
but
these
are
like
the
peaks
during
us
rush
hours,
so
we
didn't
had
like
a
full
us
rush
hours
yet,
but
it's
very
visible
that,
like
even
in
the
europe
time
zone,
we
had
picks
up
260
right
now.
This
peak
is
closer
to
55
or
maybe
40
percent
of
the
cpu
usage
on
the
on
the
main
database.
C
I'm
kind
of
surprised,
because
I
expected
a
little
more
on
the
ci,
but
maybe
more
low
top
surf,
will
give
you
like
more
thoughts
about
that.
But
it
seems
like
that
the
cpu
reduction
is
somewhere
around
like
one
third,
when
we
move
the
ci
traffic
into
its
own.
C
This
is
probably
like
the
the
most
beautiful
graph
because
the
vacuuming
activity
we
were
very
often
saturating
up
to
100
or
like
very
close
to
80
percent,
but
it's
pretty
stable
right
now.
It's
about
15
percent,
on
both
databases,
the
vacuuming
and
this.
This
is
pretty
easy,
like
the
reason
because
I
started
to
look
at
the
that
apples,
so
we
have
some
that
apple
still
happening
on
the
main
database,
as
you
can
see
here
like
break
mirror
data.
C
I
saw
also
sometimes
quite
amount
of
the
double
updates
on
the
some
match
request
data,
but
this
is
basically
pretty
flat,
like
many
databases
that
we
have
a
lot
of
trouble
of
vacuuming
after
the
composition
we
kind
of
move
a
lot
of
this
vacuuming
effectively
into
ci
because
ci
because
of
the
how
it
updates
it
updates
pretty
white
rows.
So
ca
runner
see,
I
delete
objects.
Here
I
beat
race
chunks,
ci
beers.
C
This
is
something
that
receives
like
the
most
of
the
that
tackles,
but
we've
decided
capacity,
just
vacuuming
seems
to
be
like
catching
up
and
being
at
very
low
percentage.
At
this
moment,
transactions
observed
on
the
main
writable
database.
C
D
That's
really
useful
the
transaction
we're
missing
the
ci
one
right,
so
we
should
see
the
sum
of
the
ci
transactions
somewhat
roughly
add
up
to
what
it
was.
Yes,
this
this
adapts
to
like
to
what
we.
C
Observed
last
week,
so
it's
not
that,
like
we
have
less,
we
have
basically
roughly
the
same
amount
of
the
traffic
everywhere.
It's
just
like
that.
It's
shift.
E
Thanksgiving
for
compiling
I
like
data-
and
I
think
it's
really
nice
when
you
can,
you
can
actually
see
the
impact
of
these
changes,
so
I
think
that's
a
really
really
good
result.
I'm
also
looking
for
more
data
on
it.
We
should
definitely
talk
about
this
as
well.
In
a
blog
post,
you
know
and
sort
of
highlight
you
know
the
changes
that
we
saw
and
the
impact
that
we're
seeing.
I
think
that's
going
to
be
going
to
be
useful.
F
C
C
I
kind
of
look
at
the
graphql
endpoint,
but
this
is
like
a
dropback
for
everything,
with
the
read
and
writes
so
it's
going
to
take
some
effort
like
to
find
like
this
statistical
significance
on
those
subjectivity
seems
to
be
working
faster,
but
yeah.
I
need
to
find
that
in
actual
matrix,
yet.
F
So
maybe
maybe
ask
tim
zalman
or
lucas
or
people
in
engineering
productivity
for
the
I
think
it's
the
gitlab
performance
tool
runs
and
see,
because
that's
that's
probably
close
to
me
up
to
the
user
experience
and
see
if
they
see
a
step
function.
Change
there.
C
Seems
like
a
good
idea.
I
I
think
that
basically
like
there
are
probably
like
two
ideas
like
one
looking
at
the
specific
functions
like
I
don't
know
ci
and
looking
at
the
overall
like
time
to
the
presentation
of
the
page.
I
guess
because
it's
much
harder
like
like
to
really
observe
from
individual
endpoints.
F
F
But
even
even
though
that
I
mean,
I
think
users
will
definitely,
it
looks
like
we're
more
robust,
we're
going
to
be
saturating
a
lot
less
less
print
outages.
Those
are
all
things
that
aren't
necessarily
continuous
or
in
the
moment,
but
they'll
certainly
be
felt.
And
of
course
you
know,
we've
got
our
2x
headroom
as
well
for
scaling
so
yeah.
F
Well,
I
put
a
bullet
in
c
just
I
wanted
to
echo
the
the
same
congrats
that
nick
shared
with
the
team.
You
know
witnessing
the
maintenance
window,
it
felt
very
professionally
done.
I
felt
like,
with
you
know,
being
in
a
surgical,
amphitheater
and
seeing
all
the
prep
that
went
into
it
and
the
discipline
about
staying
on
the
happy
path,
and
I
felt
like
we
were
ready
for
anything
that
could
have
happened.
F
So
you
know
the
best
the
best
job
of
something
like
this
I've
seen
us
do
so
I
could
get
to
everybody
on
that
and
keep
it
up.
E
F
A
F
E
E
A
A
Speaking
on
that
do
congrats
to
the
team
for,
like
we
run
into
a
couple
of
walls
and
the
team
methodically
dissected
the
problem
and
worked
it
out
so
that
coming
from
the
infrastructure
side,
that
is
very
nice
to
see,
because,
usually
you
know
we
got
all
worked
up
about
it.
So
just
seeing
the
response
was
super
nice.
C
We
had
a
few
extra
people
that
helped
a
lot
I
mean,
particularly,
I
think
it
was
super
useful
like
like,
like
we,
we
talked
with
they're
only
like
if
this
century
would
not
work
and
stan
would
not
confirm
the
century
is
overloaded
with
the
front
end
requests,
I'm
not
sure
what
our
decisions
would
be.
It's
rather
would
we
go
roll
back,
because
we
don't
know
what
is
happening
essentially
to
validate.
E
A
D
C
E
Well,
I
think
I
think
the
good
thing
is
that
I
hope
that
a
lot
of
the
tooling
that
was
used
here
and
some
of
the
learnings
they
you
know,
will
go
into
the
database
upgrade.
You
know
that's
scheduled
at
some
point
and
you
know
if
we
you
know
ever
have
to
do
disaster
recovery
things
for
github.com.
I
think
none
of
that
knowledge
is
going
to
be
lost
and
I
think
that's
that's
nice.
D
C
C
A
lot
of,
I
think,
like
there's
a
lot
of
no
they're
happening
concurrently,
so,
okay,
so
at
the
same
time,
right,
yeah,
yeah,.
B
E
E
Just
seeing
this,
I
think,
having
these
very
detailed
instructions,
where
the
only
thing
that
people
need
to
do
is
copy
paste
them
and
having
very
clear
sort
of
decision
criteria.
I
think
that
also
helped
reduce
the
stress,
hopefully
to
some
extent
right,
because
you
don't
have
to
make
up
things
in
the
moment.
So
it's
really
nice
that
we're
compiling
those.
E
A
Anytime
you're
doing
any
of
this,
you
really
you
don't
want
people
to
have
to
think
you
don't
want
to
increase
the
cognitive
load
so
yeah,
and
this
is
why
these
these
plans
are
so
detailed
and
what
we
talked
about.
Let's
think
about
more
specifically
about
the
exit
criteria.
A
You
can't
figure
out
everything
right,
but
if
you
have
60
of
it,
that's
60.
You
don't
have
to
go
deal
with
when
you're
in
the
middle
of
the
window.
So
now
this
was.
This
was
fantastic
and,
like
I
I
know,
I've
said
this
several
times,
but
this
was
the
most
tested
change
ever
in
the
four
years
that
I've
been
here.
So
hopefully
this
sets
a
new
bar
for
us
for
infra
for
these
kinds
of
changes.
F
It's
high
praise
from
from
jerry
he's
our
most
paranoid
seasoned
person,
so
that
doesn't
come
come
often
or
easy.
B
Great
well
yeah.
I
think
that
takes
going
to
the
next
point
I
think,
takes
us
to
the
business
of
the
working
group
itself,
so
I
opened
nmr
to
update
the
exit
criteria
to
reflect
the
completion
of
decomposition
unless
anyone
objects.
I
think
we
can
begin
the
process
of
wrapping
up
this
working
group.
B
Certainly,
there
are
follow-ups
to
decomposition
continuing
to
keep
an
eye
on
on
the
impacts
of
it
and
following
up
with
actually
removing
the
un,
no
longer
needed
tables
and
freeing
up
that
disk
space
and
then
working
on
self-managed
support
and
and
those
types
of
things.
But
I
think
in
terms
of
this
working.
B
Had
set
out
clear
exit
criteria
being
the
rollout
of
decomposition
in
production
which,
which
we've
now
done
so
yeah?
That's
that's
that's
my
proposal.
I
copied
the
the
the
process
for
disbanding
from
the
handbook
here.
So
we've
done
some
celebration.
B
I
imagine
there
will
there
will
be
some
more
celebration
as
we
get
the
opportunities,
but
yeah
next
steps
would
be
would
be
moving
the
working
group
to
pass
working
groups,
updating
the
page
with
any
relevant
artifacts
and
and
reflecting
the
the
close
date
archiving.
The
slack
channel
deleting
calendar
invites
anything
else
like
that
that
we've
missed,
but
I
guess
yeah.
So
I
have.
B
Group
one:
do
we
feel
that
we
yeah
that
we've
that
we
are
in
a
position
to
close.
A
B
And
then
I
guess
two
would
be:
when
would
we
want
the
the
last
meeting
to
be?
Would
that
be
today
or
do
we
want
another
follow-up
meeting
or
two
to
you
know,
discuss
any
anything
that
comes
out
of
further
examining
the
the
impacts
of
decomposition
and
talking
about
closing
things?
So
I
don't
have
a
strong
opinion
either
way,
but
wanna
get
others
thoughts
on
that.
F
My
my
take
would
be
because
it's
it's
9
a.m.
On
the
first
business
day
for
the
us
or
most
of
our
customers.
Are,
I
wouldn't
say,
like:
let's
make
this
the
last
meeting,
we
should
do
at
least
one
more
just
to
feel
like
we're
kind
of
like
burned
in
and
someone
some
customer
hasn't
discovered.
Some
funky
feature
that
they
only
use
and
we
have
to
sort
of
fix
or
repair
something.
F
And
then
the
the
other
thing
is
for,
for
this
group,
jerry's
been
kind
of
you
know
to
avoid
distracting
you
all
jerry's
been
working
on
a
proposal
for
some
stuff
that
comes
next,
and
so
we
can
start
to
get
people's
eyes
on
that
and
get
people's
thoughts
and
contributions
and
stuff
like
that.
So
it
doesn't
mean
we
would
avoid
shutting
this
working
group
down
and
kind
of
you
know,
celebrate
and
roll
to
the
next
one,
but
essentially
a
lot
of
the
same
folks.
E
F
Important
to
have
an
end
and
and
like
I
said,
celebrate
for
sure.
A
E
E
Yeah,
it's
it's!
It's
not
going
to
end.
You
know,
I
think
we're
not
going
to
run
out
of
out
of
work
anytime
soon.
F
Oh
yeah,
you
could
look
at
that:
8
a.m,
pacific
time
slot
so
like
an
hour
and
20
minutes
before
the
time.
Right
now,
if
that's
friendlier
to
some
folks
in
europe
on
tuesday,
I
think
we
have
the
engineering
allocation
meeting
that
will
probably
stay
but
be
renamed
but
another
day
you
know
we
rarely
have
to
have
the
the
com
stand
up
anymore,
so
take
think
about.
Taking
that
time
slot
that
works.
B
Cool
yeah
that
all
sounds
great,
so
we'll
we'll
keep
this
invite
going,
keep
the
channel
open.
I
can
at
least
start
preparing
that,
mr
to
close
things
out
from
the
handbook
perspective.
If
that
works,
but
I
I
agree,
it
would
be
good
to
have
another
week
and
examine
the
results
and,
and
yeah
start
talking
about
what's
next,
because
yeah,
I
certainly
agree.
I
think
it'll
be
a
lot
of
the
same.
B
A
lot
of
the
same
people,
same
teams,
similar
types
of
topics
so
but
yeah
it'll,
be
good
to
feel
like
this
specific
chapter
has
has
come
to
a
close
and
we
can
reconvene
under
a
different
name.
B
E
Cool
and
you
have
the
the
third
item-
yeah.
No,
that
was
just
an
fyi.
We
made
the
front
page
of
of
hacker
news
yesterday
and
I
just
wanted
to
link
it
for
those
that
are
interested.
There
was
some
interesting
discussion
on.
You
know
database
technologies.
E
I
think
people
were
overall
positive
and
thought
that
this
was
a
sort
of
pragmatic
step
forward,
but
there
was
also
a
discussion
on
you
know
the
that
lack
of
active,
active
replication
and
postgres
and
how
there's
many
new
interesting
database
technologies,
and
that
was
generally,
I
think,
an
interesting
and
interesting
read
and
you
know,
if
you
think
about.
Oh,
my
ci
minutes
are
not
working.
E
D
E
D
F
Positive
overall
is
intensely
positive
for
hacker
news
right.
So
yes,
yeah.
E
We'll
take
the
compliment
exactly
well
and
it's
a
I
think
this
is.
This
is
something
that
I'm
personally
quite
happy
about.
We
published
a
blog
post
accompanying
this
change
30
days
beforehand,
and
it
got
19
000
views
this
month,
and
I
think
that
is
also.
E
E
C
E
B
All
right
that
takes
us
to
the
end
the
agenda.
Well,
thanks
everyone
and
yeah
we'll
see
you
at
the
next
one.