►
From YouTube: 2020 11 17 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
Welcome
to
this
meeting
this
database
team
weekly
meeting,
let's
see
agenda
a
couple,
non-verbalized
topics
in
there
into
the
milestone,
figured
we'd
run
through
the
board
real
quick
see
what
needs
to
be
moved.
What
we'll
close.
A
B
I
think
you're
in
the
wrong
column.
You
are
reviewing
the
next.
A
B
I've
been
using
it
some
the
last
couple
days
the
what
is
required
for
this
or
the
kind
of
the
checklist,
and
that
issue
is
not
completed,
though
now
it's
still
a
very
manual
setup.
Okay,.
D
C
Of
our
top
priorities
for
next
my
milestone.
A
I
think
andreas
is
back
on
thursday,
any
confidence
that
this
would
be
finished
this
week.
No.
E
A
C
A
Okay,
is
it
going
to
get
finished
this
week
or
do
we
need
to
move
it
over.
A
Okay,
has
anybody
been
working
with
andreas
on
this
one.
C
Yeah,
this
is
an
open
discussion.
I
think
that
address
has
not
done
anything
there.
So
most
probably
it
won't
be
done
this
week.
Okay,.
C
Yeah,
this
is
needed
in
order
for
us.
This
is
not
a
top
priority
for
finishing
rebuilding
indexes,
but
it's
an
important
heuristic
in
order
not
to
choose
indexes
randomly
so
currently
when
we
run
the
indexing
processes
when.
C
B
A
Okay,
do
you
wanna,
should
we
move
it
over
or
do
you
wanna
see
how
it
goes
for.
B
The
rest
yeah,
I
can
see-
I
guess
the
first
parts,
there's
two,
mrs
the
first
one's
in
review.
The
second
one
is
not
quite
finished
yet
so
it
seems
unlikely,
but
I
can
move
it
depending
on
how
it
goes.
Okay,.
A
Sounds
good
and
actually
you
have
the
next
one
too.
E
C
Yeah,
we,
I
think,
that's
a
huge
one.
We
should,
I
think
we
should
split
it
to
more
issues
more
right.
B
Sorry
yeah
I
created
a
few
there's
like
three
or
four
that
I
created.
I
think
andreas
created
one
too
for
the
the
indexes,
so
maybe
we
can
decide
if
any
of
the
other
you
know
we
can
talk
about
it,
maybe
figure
out.
If
there's
more
issues
we
need
to
create,
or
we
think
that
covers
pretty
well.
What
needs
to
be
done
at
this
point.
A
All
right
sounds
like
sorry.
I
wasn't
trying
to
drag
that
around
to
glitch
on
the
board.
If
you
copy
the
link,
it'll
start
moving
it.
So
maybe
this
one
needs
to
be
promoted
to
an
epic,
so
we
can
have
the
sub
issues
beneath
it.
There's
no.
Actually,
we
already
have
an
epic
for
this
one.
B
Yeah
there's
an
epic
already,
so
I
think
maybe
this
top
level
one.
We
can
just
move
the
relevant
information
to
the
epic
and
then
just
close
this
one
and
we'll
have
the
sub
issues
to
work
off
of
okay.
C
Yeah-
and
this
was
more
of
a
it-
has
all
the
research
also
about
tools
that
we
can
use
and
methodologies,
so
we
can
keep
it
as
a
research.
One.
E
A
Okay,
if
nobody
else
wants
to
do
it,
I
can
restructure
this
one.
So
it
reflects
research
and
then
we
can
break
down
smaller
issues
into
the
epic.
C
A
Right
and
then
oh
that
one
got
drug
around
sorry
that
look
familiar
these
don't
have
anybody
assigned
to
them,
so
just
move
them
all
in
bulk.
All
the
unassigned
ones
see
honest
nodding,
pat
you,
okay
with
that
too,.
E
C
No,
no,
I'm
not
sure
about
the
rest
of
the
questions,
sometimes
without
the
for
sure.
The
updates
of
this
pizza,
when
reading
the
functional
english.
A
Yeah
well
he's
not
back
till
thursday,
I'm
sure
he's
gonna
be
catching
up
on
a
lot
of
emails
and
stuff.
So
I
think
from
probably
from
this
one
down,
we'll
just
move
them
all
over,
so
I'll
take
care
of
that
after
the
meeting.
E
D
Oh
sorry,
I
thought
you
were
saying
this.
You
were
saying
my
name.
No,
this
is
just
for
for
transparency,
so
janice
and
I
meet
twice
a
week
now
on
tuesday
mornings,
our
time
and
thursday
mornings.
Our
time
and
today
in
the
afternoon,
is
the
performance
indicator
review
for
all
groups.
It
includes
database
as
well,
and
so
one
question
that
came
up
from
scott.
The
senior
vice
president
of
prog
management
is.
D
You
know,
complaints
that
users
actually
have
that,
I
think,
would
be
a
really
interesting
project,
but
it
also
would
allow
us
to
you
know
if
we
present
that
data
in
a
in
a
form
to
other
groups
and
say
look,
you
know
we
are
here
to
help,
but
these
things
they
really
bother
people
right,
and
these
are
the
things
that
bother
them
right.
That's
a
stronger
position
to
convince
people
to
do
something
about
it,
and
so
we
we're
thinking
about
maybe
gathering
some
data
in
that
in
that
area.
A
I
think
it's
interesting.
I
would
be
curious
how
many
end
users
would
draw
a
line
from
functionality
to
database
right.
They'll,
probably
just
say
you
know,
this
part
of
the
the
application
is
slow
and
I
wonder
how
many
of
our
users
are
informed
enough
to
know
that
the
slowness
is
caused
by
the
database
right.
D
Yeah,
no,
that's
a
good
point
and
I'm
not
saying
we
are
going
to
ask
people
what
part
of
the
database
is
slow,
but
maybe
if
we
know
that
certain
parts
of
the
page
can
be
directly
linked
to
slow
database
performance
and
we
just
give
people
some
exercises.
For
example
like
can
you
perform
those
tasks
and
what
are
the
things
that
bother
you?
Maybe
they
end
up
pointing
out?
D
I
think,
with
the
honest
I
use
this
example,
it's
like
if
I,
if
I
actually
apply
suggestions
to
mrs
it
always
creates
problems
for
me
because
things
don't
get
applied
as
fast
right,
and
so,
if
we
can
indirectly
kind
of
say
people
don't
understand
that
that
has
to
do
with
slow
performance
on
the
queries,
but
they
get
really
upset
because
their
interface
locks
up
or
they
lag
right,
and
this
is
frustrating,
and
we
know
that
the
this
is
the
cause
right.
D
A
What's
the
approach
you're
going
to
take
to
figure
out
where
to
ask
those
specific
questions
about
how
do
we
coach
them
into
the
questions
and
answers?
We
want
to
get
right.
D
Yeah,
no,
I
think
that's
the
that's
the
challenge
for
younes
and
me.
It's
like
to
come
up
with
an
interesting
interview,
strategy
to
tease
those
those
things
out.
So
I
think
what
we
we
can
give
people
some
tasks
right
and
where
we
know
they
will
encounter
some
of
these
slow
parts,
for
example,
when
we're
not
going
to
tell
them
specifically
what
to
look
out
for,
but
maybe
ask
them
more
about
performance
in
general
right
or
some
of
those
things.
There
are
some
strategies
for
investigating
that.
B
C
And
that
that
ties
back
to
work
that
we
were
discussing
with
andreas
also
about
recognizing
slow
queries
and
tying,
so
we
can
start
an
effort
to
recognize
all
and
rank
slow
queries
and
tie
them
back
to
controllers.
So
one
approach,
super
technical
approach
is:
can
we
have
a
process
that
we
practically
use
the
database?
C
E
C
Result
of
that
process
will
be
that
we
have
a
a
ranked
list
that
we
know,
for
example,
that
there
are
those
three
the
top
the
most
slow
paid
with
regards
to
queries
is
the
merge
request.
E
C
Let's
say,
and
we
will
have-
we
will
know
that
going
a
bottom
job,
knowing
that
there
are
those
three
queries
that
are
on
average,
that's
slow
and
we
know,
and
we
can
tie
them
because
with
marginalia
we
track
for
every
query
where
it
comes
from
and
then
go
back
and
say:
okay,
so
we
know
that
this
query
is
slow,
but
by
itself
it
does
not
say
anything
to
us.
But
knowing
that
this
query-
or
these
sets
of
queries
goes
back
slowing
down
that
specific
view,
a.
E
C
Means
that
then,.
E
C
Can
run
the
tests
that
and
the
interviews
that
the
fabian
says,
and
we
can
also,
we
also
know
where
who
to
reach
afterwards,
because
each
page
more
or
less
has
an
owner
yeah.
A
And
you
kind
of
answered
my
question
about
marginalia,
but
I
guess
the
follow-up
question
is:
is
marginalia
a
manual
process
like
when
we're
do
you
have
to
manually
fill
out
data
for
it
to
be
populated
by
marginalia,
and
I'm
not
even
sure.
If
I'm
asking
that
question
correctly
or
is
it
fairly
automated
in
that
it
knows
which
controller
is
making
that
call.
C
A
C
That's
important,
so
we
don't
we,
we
are
not
blocked
by
any
change
from
other
teams.
B
C
D
D
Then
we
can.
We
can
use
that
to
prioritize
work,
and
we
can
also,
you
know,
put
this
maybe
into
some
interesting
tracking
metrics
for
size,
sense
and
say:
okay,
you
know
this.
Is
you
know
these
are
the
slowest
performing
pages
you
know
over
time?
This
is
the
impact
on
users
right
and
this
you
know
these
are
the
specific
steps
we
take
to
to
improve.
I
think
that
that
can
show
a
lot
of
impact.
You
know
on
actual
folks,
and
I
think
that
would
be
quite
quite
fun
or
quite
interesting.
A
D
Yeah
yeah,
we
just
talked
about
it
this
morning.
I
think
this
is
as
in
I'm
just
reading
stuff
right
and
talking
about
it
with
the
honest
and
I
think
the
next
the
next
up
here
would
maybe
to
like
write
up
that
epic
and
say
these
are
these
are
the
next
steps?
This
is
what
we
can
do,
because
the
question
is
also:
how
easy
is
this
right
and
how
much
time
would
it
take?
We
would
need
to
evaluate
it.
I
think
would
be
really.
D
I
think
it
would
be
interesting
because
I
think
that
that
would
be
really
positive
for
for
the
database
team.
You
know,
as
you
know,
this
is
why
why
these
queries,
you
know,
are
actually
really
impactful
and
we
know
I
think,
from
some
some
research
that
perceived
slowness
is
a
huge
detractor
for
user
interfaces,
but
if
things
lag,
people
get
really
upset,
they.
E
D
E
C
We
don't
know
what
what
about
others,
so
I'm
really
frustrated
with
the
merge
requests.
The
page
and
the
the
assigned
issues
page
and
searching
for
those,
but
maybe
others
have
other
pain
points.
So
craig
is
asking
about
the
postgres
checkup
report.
So
what
I
touched
very
briefly,
the
technical
part
of
that
is.
Can
we
do
what
the
postgres
check-up
report
does
and
provides
us
with
15
top
queries,
but
take
snapshots
every
30
seconds
or
one
minute
so
that
we
can
have
history
and
we
can
use
that
history?
C
E
C
Delay
and
take
snapshots
so
that
we
know-
and
we
start
tracking
all
those
queries
and
not
only
have
the
top
15.
We
may
want
to
do
different
analysis
there
because,
for
example,
the
the
postgresql
report
has
the
15
most
expensive
queries
in
general,
so
14
out
of
those
15
may
come
from
ci
deals
and
are
from
background
processes
and
may
not
be
related
to
slowness
in
the
interface.
So
if
we
have
a
quick
check,
I
did
the
thing
that
we
have
something
we
draw
something
like
5000
queries
in
digital
statements.
C
We
can
see
a
lot
more.
We
can
do
an
analysis.
There
have
a
pivot
table
or
whatever,
and
then
you
know
know
about
per
job
or
per
controller
or
per
page
et
cetera,
et
cetera,
et
cetera,.
A
D
I
had
I
had
no
idea,
but
I
think
that
would
be
really
fun
to
get
into
a
workable
shape
and
then
you
know
just
see.
Okay,
you
know
the
usage
on
gitlab.com
for
the
pages
where
those
things
run.
You
know
like
how
many
thousands
of
times
this
page
gets
loaded
right
every
every
day,
right
and
then
you
you
can
do
all
sorts
of
rankings,
but
yeah.
That
would
be
interesting,
patrick
I'm
interested
in
your
thoughts.
What
what
do
you
think.
B
Yeah
yeah,
I
I
think
this
is
what
we
needed
for
a
long
time
really.
You
know,
I
think,
the
last
six
months,
or
so
we've
been
working
on
partitioning
on
and
off
and
but
not
really
with
a
clear
end
goal
other
than
like.
Let's
just
prove
partitioning
works,
we
don't
really
know
what
we're
like.
Now
we
have
events
table
on
the
horizon,
which
I
think
is
a
good
fit
for
partitioning.
B
After
that
we
don't
really
know
like
what
are
we
going
to
do
with
it,
because
we
don't
know
where
to
go
in
the
app.
B
So
I
think
that
this
is
critical
to
making
that
decision,
and
I
think,
like
you,
said
where
everyone
was
saying
that
we
have
there's
a
general
feeling
that
the
app
is
slow,
that
creates
user
frustration,
but
I
think
often
that's
not
really
linked
back
to
the
database,
and
so
I
think
database
does
not
get
the
attention
that
it
deserves
as
a
result
of
that
and
that
the
underlying
issues
are
harder
to
correct.
B
E
B
D
Thank
you
for
for
sharing
that,
and
I
think
you
made
a
really
good
point
this
may
it
may
also
be
the
case,
and
I
just
don't
know,
because
I'm
a
little
bit
ignorant
at
the
moment.
Maybe
the
database
queries
are
really
not
the
issue
right
for
most
of
the
perceived
slowness
right.
I
know
that
memory
has
done
a
lot
of
work
of
like
actually
scaling
down
images
right,
because
you're
loading
60
megabytes
of
like
avatar
data,
even
though
you
don't
need
to
right.
D
So
there
may
be
lots
of
other
things
that
are
also
going
on,
but
maybe
this
is.
This
is
good
for
us
locally
to
actually
see
you
know
what
impact
do
we
have,
but
maybe
in
the
in
the
long
term.
I
think
this
is
a
great
point
in
terms
of
how
to
assess
performance
also
to
understand
you
know
for
some
of
those
pages,
what
is
actually
causing
issues?
I
I
don't
know
again.
I
don't
know
how
much
breakdown
we
actually
have
of
what
contributes
how
much
right
and
that's
generally
quite
interesting.
E
C
C
If
I
had
this
solution
now,
it
will
be
like
you
know,
just
click
click
bring
me
all
the
controllers
that
use
of
the
events
table.
I
have
all
the
the
buttons.
I
have
everything
we.
We
can
also
have
rates
there,
how
often
those
squeezes
run
and
other
stuff.
If
we
do.
If
we
go
on
that
way,
and
so
it
will
also
help
us
informal
decisions
on
access
patterns
and
also
help
us
yeah
identify
other
problems,
but
yeah
for
partitioning
is.
It
is
also
very
important.
B
Yeah,
I
think
we
have
a
little
bit
of
a.
I
think
the
user
survey
would
be
good
too,
because
we
have
a
little
bit
of
a
problem
in
the
way
that
we
kind
of
measure
these
things
currently,
which
is
you
know,
whenever
we
have
a
database,
merge
request
or
any
kind
of
database
changes,
we're
always
under
the
assumption
that
gitlab
is
the
biggest
user
of
gitlab.com,
and
so
everything
is
kind
of
tested
against
the
gitlab
project,
the
namespace
etc.
B
But
that's
the
assumption
that
our
workflow
is
similar
to
how
everyone
else's
workflow
is.
We
think
like?
Oh
for
us,
the
merge
request
page
is
slow
because
we
have
40
000,
merge
requests,
but
that
doesn't
necessarily
hold
true
for
everyone.
We
don't
really
know
what
pain
points
they're
experiencing,
because
we're
only
seeing
the
things
that
we're
using
on
a
daily
basis,
they
could
be
using
some
other
or
the
app
much
more
heavily
than
we
are
in
some
way
a
different
way
than
we
are
and
then
so.
D
Yeah,
I
know
that's
a
that's
a
good
point
and
I,
I
think
the
I
think
what
I
would
like
to
do
is
to
to
compile
a
combination
of
some
quantitative
data
like
what
we
have.
You
know.
We
know
how
slow
or
fast
things
are,
but
also
get
user
sentiment
right
and
luckily,
I
think,
we're
pretty
flexible
in
that
regard.
We
could
reach
out
to
gitlab
developers.
That's
zero
effort
right.
D
We
can
do
you
know,
I
don't
know
I'm
exaggerating,
but
we
could
do
10
interview
interviews
in
like
two
days,
because
people
are
generally
very
helpful,
but
also
if
we
reach
out
to
ux
research,
you
know
it's,
it's
not
difficult
to
find
people
who
would
have
valuable
information
to
share
because
it's
not
in
my
case
it's
often
systems
administrators
that
use
geo
right.
A
And
and
giannis
kind
of
answered
the
question
I'm
going
to
pose
here
or
a
concern,
I'm
feeling
from
this,
so
we
we
started
approaching
events
table
because
of
known
issues
with
it
right,
the
sheer
size
and
volume.
We
thought
that
partitioning
would
help
us
to
tackle
that
and
some
of
the
complaints
about
functionality
like
not
being
able
to
display
more
than
a
year
some
of
the
timings
on
retrieving
that
data.
A
So
we
knew
that
the
events
table
was
a
problem
both
in
performance
and
volume,
and
my
concern
here
is
that
I
and
giannis
kind
of
clarified
by
saying
this
will
help
us
to
better
inform
how
to
tackle
events
as
a
an
example.
A
But
my
concern
here
is
we're
gonna
find
more
problems
that
may
be
a
higher
priority,
which
is
a
good
thing.
We're
just
gonna,
keep
adding
to
our
backlog
of
more
things
that
we
should
be
doing
so.
The
outcome
of
this
might
be.
We
just
tripled
our
backlog,
but
this
could
also
help
our
case
of
hiring
more
developers.
So
I
have
a
sense
of
dread
on
doing
this.
I
guess
is
what
I'm
trying
to
say.
I
think
it's
a
great
idea,
it'll
be
interesting
to
see
what
the
outcome
is.
D
A
C
Can
I
also
share
that
I
have
started
my
learning
learning
internship
issue,
so
you
will
help
me
build
my
reach,
my
okr,
which
will
be
to
reach
out
to
other
teams
to
help
us
with
partitioning.
D
No,
but
I
I
I
share
your
your
view
here
that
will
probably
answer
like
uncover
quite
a
few
other
things
and
that's
that's
in
a
way.
It's
good.
You
know,
it
probably
means.
Maybe
you
know
some
re-prioritizing,
but
that's
also
normal,
and
I
I
think
in
general
gitlab
is
pretty
good
about
having
a
short-sighted
roadmap
right.
We
haven't
made
commitments
to
somebody
for
something
to
be
delivered
in
one
and
a
half
years.
D
So
I
think
if
we
have
a
good
reason
to
do
some
other
things
as
well
right
or
replace
priorities,
I
think
that's
that's
fine.
I
think
the
important
thing
is
that
we
know
why
we're
why
we
are
doing
that
right
and
I
think
what
would
be
cool
if
we
could
get
to
this
point
and
probably
take
a
while
right
is
to-
and
this
is
how
I
actually
started
thinking
about
it,
because
I
have
this
performance
indicator
review
meeting
right
and
I
I
read
that
meeting
a
little
bit
because
I
I
don't.
D
A
C
C
Now
we're
going
most
probably
to
to
address
events.
This
is
open
still.
We
have
to
be
sure
that
we
can
address
events,
because
there
are
a
couple
of
different
access
patterns
and
going
to
events
or
a
similar
table
that
has
foreign
keys
and
some
other
things
that
we
did
not
have
with
audit
events.
So
from
an
engineering
perspective.
Audit
events
was
a
very
nice
interest
for
us.
We
went
in
easily
not
very
difficult
a
lot
of
difficult
problems
solved,
but
not
everything
there.
C
Now
we
can
tackle
events,
and
then
we
will
be
more
or
less
confident
that
we
have
the
tooling
there
and
everything
that
patrick
is
building
for
the
past.
How
many
months-
and
we
have
run
this
also
through
two
very
big
tables,
because
audit
vents
is
at
240
million
records
or
something
like
that
and
the
events
is
way
larger.
So
we
we
will
be
confident
and
then
we
can
do
our
enablement
work
and
enable
ours
and
help
others
to
do
that.
D
Well-
and
I
also
think
in
an
ideal
world-
and
this
yeah,
who
knows
how
it's
going
to
go,
obviously
has
only
a
certain
percentage
of
his
time,
but
we
may
be
able
to
you
know:
do
this
now
right
and
get
some
results
in
the
next
milestone
or,
however
long
it's
going
to
take,
and
then
the
outcomes
of
that
can
inform
priorities,
sort
of
in
two
milestones
or
three
milestones
right,
because
it
shouldn't
really
be
disruptive
to
what
happens
now.
D
E
A
A
C
So,
okay,
so
we
have
a
consensus
that
this
is
important.
So
we
agree
that
the
technical
part
of
it-
because
it
has
this
technical
implementation-
that
we.
E
A
Right
13-7
right
not
for
today,
and
it
sounds
like
we're
in
agreement
that
in
parallel,
we
continue
down
with
the
events
work
until
maybe
this
data
immediately
proves
that
hey
actually,
this
table
would
be
better
suited
for
partitioning,
but
that
would
have
to
be
a
pretty
quick
turnaround
if
we're
going
to
jump
into
events
partitioning
next.
E
C
A
So
this
is
from
last
week,
pat,
you
got
the
first
section
here.
A
E
A
Is
audit
events
going
to
be
done
this
week?
You
think
pat.
B
A
And
then
what
do
we
call?
Another
thing
that
we
just
talked
about
the
user
interviews.
A
D
We
can
call
it
a
a
discovery,
effort
on.
D
D
We
spoke
about
it
this
morning.
I
I
have
to.
I
can
connect
with
the
others
tomorrow
morning
again
to
see
what
we
can
actually
do.
So
this
is
really
hot
off
the
heart
of
the
press.
I
think
the
next
steps
would
actually
be
to
write
up
the
epic
and
you
know,
define
some
some
tasks.
A
C
No,
we
split
the
clean
up
the
schemas,
the
schema.
A
Pretty
much
at
the
end
of
the
agenda
anything
else
we
wanted
to
cover
today.