►
From YouTube: 2021 01 12 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
Hello
welcome
to
this
version
of
the
database
weekly
meeting.
It
is
january
11th
and
we'll
jump
right
into
it,
so
it
is
tuesday
first
thing
so
we'll
go
through
the
infra
depth
review.
I
looked
at
the
board
this
morning.
A
B
Let's
see
so,
I
briefly
spoke
with
the
yesterday.
We
texted
a
bit
about
this.
We
are
collecting
marginalia
and
doing
some
analysis.
We
do
some
sampling
from
production
last
week.
I
would
like
to
know
if
you,
if
you're
interested,
that
we
execute
this
for
all
this
select
a
star
from
table
or
id
equal
to
something.
B
B
Like
it's
based
on,
I
did
with
nikolai
we
did
a
gather
of
6
000
rows
more
or
less
like
20
seconds
everything
that
was
active,
it's
20
seconds,
so
I
can
add
this
for
the
other
tables.
I
remember
I
did
for
just
projects
when
they
collided
for
just
projects,
there's
more
four
tables
that
we
have,
that
we
could
collect
and
give
you
the
information.
D
Yeah,
so
what
I
added
in
the
issue-
and
we
can
continue
the
discussion-
the
issue
I
have
also
mentioned-
andreas
being
the
dress
and
patrick
there
is
that
already
the
data.
There
are
pretty
very
useful
with
respect
to
what
we
have
right
now
and
on
top
of
that,
what
is
missing
in
the
analysis
that
nikolai.
B
D
Is
that
he
only
did
an
analysis
per
job
type
for
sidekick
jobs?
What
would
if
we
are
going
to
create
a
summary
going
forward
in
the
future?
And
it
will
be
nice
to
also
have
a
summaries
accounts
for
the
groupings
by
web
controller
action
and
also
one
count
for
the
only
web,
because
those
are
queries
that
come
from
some
other
place
in
the.
D
Some
additional
post
processing
over
the
the
raw
data,
nothing
more.
D
With
respect
to
what
we
have
now,
it
feels
like
at
least
to
me
that
this
is
a
great
step
forward,
because
we
already,
for
example,
projects.
We
can
see
10
different
places
where
the
queries
come
from.
D
What
I'm
not
sure-
and
I
would
love
other
stupids
in
there-
is-
how
much
time
we
should
sample
in
order
to
to
get
an
interesting
sampler
sample
so
that
we
can
have
the
information.
We
need
great.
B
Yeah,
like
I
have
a
few
points
more
to
share
with
you
with
the
team.
First
of
all,
I'm
looking
for
pg
sentinel
that
we
can
gather
more
states
of
the
transactions.
B
So
of
course
we
need
to
test
this,
and
also
there's
some
painful
part
here
that
we
need
to
switch
over
is
lash
failover,
because
we
need
to
restart
the
box
to
accept
this
statement,
but,
like
I'm,
collecting
several
things
that
requires
a
restart,
so
I
think
can
be
useful
if
we
try
to
put
all
of
them
together,
but
yeah.
This
is
pages
sentinel
every
anyone
else
has
any
ideas
on
these
or
suggestions.
Please
bring
me
the
issue.
B
The
second
point
is
more
regarding
what
we
are
doing
now
manually,
I'm
trying
to
collect
these
comments
on
what
we
have
automatically
like
I'm
trying
to
get
the
concept
on
how
to
do
that
using
poses.
As
a
supporter,
I
think
there
is
not
too
much
rocket
science
there.
So
we
can
get
this
pretty
straightforward
and
keep
you
like.
B
If
you
have
any
thoughts
on
this
as
well,
I
am
adding
that
and
the
third
one
is
something
that
I
heard
from
stan
some
time
ago
and
I
found
out
in
my
skin
today
that
we
have
some
questions
that
are
pretty
big.
I
was
talking
with
grassguard
today
and
he
wanted
as
well
to
know
the
marginalia
to
know
where
who
is
calling
and
from
where
comes
the
context
of
this
statement.
B
But
unfortunately,
this
square
is
really
long
and
we
do
not
save
in
the.
We
do
not
save
the
whole
query
in
the
static
in
the
query
field
that
is
limited
to
1048
bytes.
The
proposal
here
is
to
increase
to
the
double
okay.
These
were
the
main
points
I
wanted
to
share
with
you
guys
with
everyone,
and
any
feedback
is
welcome
and
we
can
keep
it
ready
on
them.
C
Can
I
answer
a
quiz,
quick
question
about
thanos
about
the
yeah
exporting
that
those
comments?
What
is
the
source
for
that?
I
mean
you,
you
explain
like
we
use
pg
stat
activity
to
do
the
sampling,
and
that's
that
is
clear
how
that
works.
We
also
use
that
to
export
the
data
into
thanos
or
where
does
that
come
from.
B
Yes,
because
I
can,
I
have
pauses
a
sparta
running
on
the
box
and
I
can
export
this
automatically
to
somewhere
like
nowadays
what
I
did.
We
did
a
process
like
a
small,
let's
say,
shell-
that
connects
to
the
database
and
connect
this
each
20
seconds
and
then
manually
have
to
take
this
dump
from
this
or
somewhere
to
import
somewhere,
and
then
I
do
all
the
process
that
I
want
by
select
statements.
B
My
idea
here
is
to
make
something
automated
that
will
be
exporting
constantly
this.
We
can
set
up
a
threshold
of
time
that
we
pres.
We
keep
this
data,
let's
say
one
week
or
two
whatever
we
need
but
keep
this
running
automatically.
Then,
when
we
need
we
have
this
information
there.
I
thought
this
can
make
our
life
easier
to
collect
this
data
and
keep
it
visible
to
everyone.
What
are
your
thoughts
on
that.
C
Yeah,
that's
an
interesting
approach,
so
we
would
have
postcas
exporter
looking
at
pitches
that
activity
and
then
pushing
the
information
to
thanos
or
to
prometheus.
Yes,
yeah.
What
would
be
the
frequency
of
that?
I
mean
I
think
closely
exporter.
Does
it
once
per
minute
or
so.
B
B
A
Is
there
anything
the
database
group
here
needs
from
infra?
Is
there
anything
we're
waiting
on
or
blocked
on
or
don't
have
a
status
on.
B
B
C
It's
at
the
bottom
of
the
attendant
there.
There
is
an
issue
there.
Patrick
was
looking
at
that
yesterday
and
we
were
basically
seeing
and
patrick
just
correct
me.
What
was
wrong,
what
we
were
seeing.
Ci
pipelines
are
being
created
pretty
regularly
at
five
minutes
past
the
hour-
and
this
is
I
mean,
the
majority
of
those
peaks
that
we
observed
happened
five
minutes
past
the
hour.
C
So
so
maybe
there
is
a
there
is
a
correlation
there,
and
we
also
know
that
we
have
scheduled
pipelines
and
a
lot
of
them
are
kicking
off
are
supposed
to
kick
off
at
the
top
of
the
hour
basically,
but
they
might
just
end
up
being
kicked
off
five
minutes
after
the
hour
there.
C
D
D
C
C
Let's
say
you're
kicking
off
that
scheduler
at
the
top
of
the
hour,
and
we
we
would
need
to
kick
off
a
lot
of
pipelines
at
that
point
in
time,
and
we
start
doing
that.
Then,
basically,
all
those
pipelines
that
kick
off
at
the
same
time
and
the
reason
why
it's
five
minutes
past
the
hour
could
be
that
sort
of.
When
you
look
at
this
at
the
very
top
of
the
hour,
then
maybe
not
all
pipelines
are
being
triggered,
but
at
five
minutes
past
the
hour,
all
of
them
are
being
eligible
for
being
triggered.
C
So
maybe
that
that
explains
why
they
are
being
kicked
off.
That's
what
I'm
I'm
trying
to
find
out.
You
know
the
the
unix
kron
scheduler
has
this
ability
to
distribute
across
the
hour,
if
you
like
it
too,
basically
not
kicking
off
at
every
top
of
the
hour
but
distributing
things
and
that
that
could
be
an
option
there
too,
for
those
ghetto
pop
ones,
but
yeah
kind
of
like
still
looking
into
that.
But
it's
an
interesting
lead.
B
Yes,
I
did
in
the
past
some
because
this
was
exactly
the
same
moment
that
we
were
crashing
when
we
had
the
snapshots
being
executed
and
we
removed
the
snapshots,
of
course,
from
one
node
and
we
got
better,
but
I
remember
to
investigate
a
lot
of
issues
happening.
At
the
same
time,
I
will
put
you
some
links
on
things
that
we
have
found
in
the
past,
just
to
give
you
some
reference
if
it
makes
any
sense.
Okay,.
C
B
D
C
B
C
A
A
All
right,
unless
there's
anything
else,
burning
we'll
move
on
to
the
next.
So
it's
near
the
end
of
the
milestone.
We
have
quite
a
bit
in
here
and
we
have
friends
and
family
on
friday
and
the
milestone
ends
over
the
weekend.
A
So,
let's
run
through
these
real
quick,
pat
you're,
the
closest
one
on
this
first
one
here,
the
mr
pipeline
is
running
against
pg-12.
E
F
E
A
A
A
All
right,
jonas.
D
Yep,
this
is
in
review.
We
have
to
figure
out
how
to
deal
with
this,
so
one
problem
with
this
one
is
that
if
we
go
conservative,
we
need
six
months.
D
So
I
have
assigned
dmr
to
both
andreas
and
pat,
so
that
we
can
check
it
all
together
and
think
about
it.
There
is
one
interesting
thing
here
so
for
this,
so
we
can
test
with
production
data,
but
we
cannot
test
with
production
hardware.
So
I
know
that
running
this
query
against
postgres
ai.
We
have
a
worst
case
or
a
lot
of
times.
It
takes
around
one
one
and
a
half
seconds
to
update
100
records
so.
D
With
that
we
need
six
months
and
something
like
if
you
click
there.
I
have
some
very
international
stats,
130
000
jobs
or
something
like
that,
but
I
bet
from
our
experience.
Production
should
go
way
faster
and
we
know
that
postgres
ai
sometimes
is
slow
on
updates,
but
we
cannot
risk
it.
So
we
have
to
figure
out.
How
can
we
check
and
update
we
that
also
needs
a
ddl
adding
the
column?
How
can
we
take
it
against
production
data
yeah?
I
guess
a
production
server.
E
E
Yeah
that
one
is
in
review-
hopefully
it's
still
gonna
get
merged
this
week.
I
think
hopefully
it
will
work.
I
think
we're
narrowing
down.
D
A
I'm
good
sorry,
I'm
gonna
go
back
on.
A
A
I
was
just
gonna
blame
you
all
cause
you
all
froze
up.
Should
we
should
we
drag
the
events
id
over
to
39?
It's
clearly
not
going
to
close
in
this
milestone.
D
B
D
To
think
about
so,
if
we
can
test
somewhere
and
we
can
be
sure
that
the
update
takes
300
milliseconds,
we
can
schedule
accordingly
or
increase
the
bad
size
or
something
that
will
allow
us
to
run
it
in
two
months.
It's
so
I
would
propose
to
leave
it
there,
but
we
will.
We
should
check
it
and
then
the
the
last
thing
we
could
do
if
we
cannot
figure
out
another
anything
else.
Would
we
we
could
ask
alberto
for
a
solution
somewhere
to
to
use
a
server
or
something,
but
let's
think
about
it.
D
A
Okay
sounds
good.
Andreas.
C
That
one
has
been
blocked
for
a
while,
but
the
there
has
been
some
activity
today
on
the
configuration
change
so
from
ours.
That's
done
basically,
but
it's
not
yet
enabled
because
it's
lacking
a
configuration
change,
but
that
happens
soon.
So
I
would
leave
it
there,
perhaps
even
close
it,
but
yeah.
Let's
wait
for
a
couple
of
more
days.
Maybe
that's
that's
completely
done
then
sounds
good.
That.
E
Yeah,
the
mr
for
that
was
merged
right
now,
it's
running
in
running
in
like
an
allowed
to
fail
state,
so
basically
we're
just
monitoring
it
to
see.
If
it's
going
to
have
any
issues
I
haven't
seen
any
so
far,
but
what
I'll
probably
do
is
close.
This
issue
maybe
and
then
create
a
follow-up
just
to
change
that
convert
that
later
to
be,
you
know,
break
the
pipeline
when
it
fails.
C
This
is
still
open,
but
I
think
it
should
be
ready
for
review
again
by
the
way,
thanks
pat,
for
really
paying
attention
to
to
that
detail
with
the
unique
index
versus
the
unique
constraint
that
is
really
good
eyes.
C
So,
thanks
for
pointing
that
out
I'll
hand,
it
back
to
you
maybe
later
today,
yeah.
E
D
D
E
C
E
Yeah,
it's
an
issue
still,
I
think
we
have
talked
last
week
when
we
had
talked
about
this
one,
but
there's
some
ramifications
for
this
relating
to
the
other
issue
that
has
to
do
with
the
atomic
internal
id.
So
I
want
to
tackle
this
one
as
a
follow-up,
but
next
milestone,
probably
okay,.
C
Yeah
this
one
is
similar
to
the
other
one
waiting
for
the
infrasight
change.
This
is
happening
today
in
staging,
I
think
so,
yeah
that's
on
track.
Basically,
okay.
A
F
I
was
just
about
to
suggest
that
we
may
so
maybe
we
can
quickly
walk
you
through
the
boards
shouldn't
take
too
long,
and
that
may
actually
help
us
with
some
decision
making
with
regards
to
planning,
because
it
makes
some
of
the
things
that
I
think
were
raised
in
the
process
discussion
a
lot
more
obvious,
so,
for
example,
how
many
epics
I'm
working
on
right
these
kinds
of
things.
A
F
Can
you
see
my
screen
super
okay?
So
let's
talk
about
the
the
build
board
first,
and
so
please
stop
me
when
you
have
any
questions
also
for
for
giannis.
This
is
a
proposal.
It
doesn't
mean
that
we
have
to
do
it
in
that
specific
way
right.
So
this
is
really
a
small
just.
This
is
how
this
can
look
like.
F
So
the
first
thing
is
I
in
or
we
in
geo.
We
use
a
very
similar
board
to
this
one
here
and
we
call
it
the
the
build
board-
and
there
are
a
few
things
to
to
know
so.
This
board
here
aggregates
from
group
database
and
from
this
additional
label
here
database
active
and
the
reason
for
doing
this
is
that
it
allows
us
to
control
not
only
what
is
in
these
workflow
stages,
but
also,
what's
in
the
open
and
closed
columns
right.
F
These
aren't
ready
for
development
as
in
the
next
milestone,
or
maybe
even
like
one
or
two
milestones
or
work
that
is
actually
in
development
right
now,
so
this
is
essentially
a
replacement
ish
to
the
the
milestone
board
that
we
just
walked
through,
and
the
content
is
actually
very
similar
right.
It
lists
all
of
those
items.
F
F
Currently,
there
is
nothing
labeled
as
in-depth
right
most
things
are
in
review
and
some
are
blocked
right.
So
you
can
visually
kind
of
see
that
theoretically,
people
should
be
able
to
pick
up
some
things.
You
know
this
week
and
work
on
it
or
the
board
is
wrong,
and
one
thing
that
also
works
here,
and
this
is
what
we
started
doing
in
geo,
which
is
maybe
where
we
could
be
at
some
point
is:
if
you
now
group
these
things
here
by
epic,
you
get
swim
lanes.
F
F
You
know
some
automating
database
migrations.
That's
closed.
Then
we
have
these
primary
overflow
things
here.
You
know
database
migration,
testing,
reindexing,
partitioning
database,
schema
validation,
partitioning
and
then
all
of
this
here,
which
is
essentially
operational
right.
So
these
things
are
maybe
things
that
don't
belong
to
a
specific
epic
and
that
makes
kind
of
sense
like
bugs
right.
Maybe
some
of
the
info
dev
things.
F
So
what
this
board
would
actually
allow
us
is
to
be
a
little
bit
more
specific
for
milestones,
right
and
say,
or
for
our
sort
of
next
thing
and
say
hey.
We
want
to
actually
spend
most
of
our
time
in
this
epic
here
and
maybe
in
partitioning.
F
That's
it
right,
and
the
other
thing
is
we're
going
to
like
move
away,
because
we
already
have
a
lot
of
operational
bits
in
here.
So
that's
this,
this
board.
F
What
needs
to
happen-
and
I
think
this
is
this-
is
a
philosophical
thing
and
then
I'll
pause.
You
don't
see
milestones
here
right,
it's
it's
not
milestone,
focused
it's
sort
of
focused
on
flow
right.
I
personally
think
this
is
good,
because
I
believe
what
we're
actually
aiming
for
is
moving
things
from.
You
know
ready
for
development
to
closed,
essentially
as
fast
as
we
we
can
right.
That's
the
cycle
time.
The
milestones
are
essentially
gitlab's
release
policy
right
for
for
self-managed.
F
F
This
is
the
epic
we're
going
to
focus
on
in
the
next
milestone
in
the
next
month.
Right,
and
these
are
the
issues
that
we
are
very
likely
going
to
work
on
right
and
then
they
can
go
into
ready
for
development.
We
can
label
them
accordingly,
that's
fine
right,
but
I
and
I
this
is
a
controversial
opinion
right
also
in
the
proper
team.
F
I
personally
don't
really
care
about
milestones
that
much
because
I
would
like
things
to
just
be
done
as
fast
as
we
can
in
the
priority
order,
and
if
you
deliver
to
dot
com
right,
it
doesn't
really
matter
anymore.
You
know
if
it's
done
on
the
10th,
that's
fine!
If
it's
done
on
the
18th,
that's
fine
and
okay.
If
it's
on
the
20th,
that's
going
to
miss
that
specific
release,
there
are
some
situations
in
which
that's
problematic,
but
more
often
this
is
just.
It
should
be
a
snapshot
right
in
time.
F
Saying
like
this
is
what's
done
at
that
moment,
that's
what
we
are
going
to
to
bundle
up.
So
my
proposal
here
and
janice's
as
well
will
be
maybe
to
go
forward
and
use
something
like
that,
with
the
other
words
that
I'm
going
to
explain
in
a
little
while
thoughts.
A
I
have
a
couple
questions
that
I
wrote
in
agenda
I'll,
just
verbalize
them
that
so
and-
and
I
I
tried
to
write
this
down
in
the
process
issue,
so
there's
there's
a
step-
zero,
that's
still
kind
of
missing.
For
me,
how
does
how
do
issues
go
from
just
being
in
the
backlog
to
labeled
as
active
or
labeled
as
database
triage?
A
F
No,
so
the
triage,
the
triage
process,
we
have
a
separate
board
for
that.
We're
going
to,
I
think,
explain
in
a
little
while,
but
in
terms
of
when
does
something
get
like
sort
of.
When
does
it
get
the
active
label?
When
does
it
go
into
the
build
board?
F
Okay,
you
know,
given
our
priorities,
what's
the
next
thing
here
right
and
then
you
you
just
apply
the
the
label
and
you
fill
the
ready
for
development
column.
F
The
interesting
thing
is
that
you'll
probably
see
that
quite
a
few
things
pile
up
here,
so
you
I
like
to
keep
these
boards
really
tidy
right
and
if
something
sits
and
ready
for
development
for
longer
than
a
couple
of
weeks.
It's
probably
you
know
too
stale
right.
It's
like
it's
actually
not
a
priority.
It's
just
hanging
out
there.
You
should
remove
it
and
re-prioritize,
so
I
think
it
keeps
it
very
lean
right.
It's
like
this
should
never
be
super
full
in
my
opinion,
so
the
triage
flow
I
can
explain
in
in
a
second.
A
Yeah,
it
sounds
like
there's
a
prior
step,
so
this
is
what
the
board
the
development
group
should
be,
focusing
on
and
there's
a
prior
step.
The
product
looks
at
all
of
the
issues
and
figures
out
what
needs
to
come
in
okay
and
then
my
other
question
is,
and
it
might
be
a
similar
answer.
You
know
how
does
this
help
with
your
milestone
kickoffs,
because
that's
still
a
thing
that
needs
to
be
delivered
right
and
we
all
need
to
kind
of
agree
what
we're
focusing
on
for
the
milestone.
F
F
That
being
said,
as
soon
as
you
start
actually
organizing
yourself
into
epics
right,
it
becomes
pretty
simple
right
because
I
can
say
like
I
can
show
you
my
this
is
my
geo
planning
like
issue
for
for
13.8.
These
are
the
epics
that
the
team
is
currently
working
on.
These
are
the
next
issues
in
these
epics.
F
That's
what
I
talk
about.
We
move
them
onto
the
board
right
and
that's
kind
of
it
right,
so
it
shouldn't
really
be
a
lot
of
work,
because
you
should
talk
about
this
pretty
frequently
once
a
week
right
and
then
you're
just
saying,
okay,
what
do
we
think
is
going
like
going
to
be
the
next
thing
for
for
the
next
milestone?
So
it's
a
little
bit
of
like
wrangling,
but
I
think
that's
I'm
happy
to
do
that.
D
And
also,
can
I
say
what
you
you've
shown
from.
A
D
It's
very
close
to
what
patrick
and
andreas
were
discussing
about
grouping
on
epics,
so
the
planning
was
there.
If
we
check
it
again,
it
is
by
epics
and
then
one
or
two
or
three
people
grouped
for
a
milestone
to
do.
For
example,
two
people
group
to
do
geopa
patron
support,
for
example-
and
yes,
this
feels
very
very
close
to
the
discussion
we
had
in
the
other
issue.
D
C
I
was
going
to
say
sorry,
no
sorry,
please
go
ahead.
I
liked
seeing
the
the
group
by
epic
few
we
might
wanna.
We
might
need
to
clean
things
up
a
little
bit,
but
realizing
that
those
are
eight
different
epics.
Those
issues
is
pretty
good,
so
that's
that's
the
nice
way
to
visualize
it
and
also.
C
I
think
we
spend
a
lot
of
time
working
on
issues
that
are,
you
know,
preparing
issues
looking
at
things
that
are
not
on
the
milestone
necessarily
so
this
and
together
with
the
triage
board,
I
think
it
makes
just
more
visible
what
we
are
actually
spending
time
on
and
that's
always
good
to
I'm
sold
on.
C
C
F
Then
there
are
two
other
boards
that
I
quickly
wanted
to
discuss,
one
of
which
is
probably
less
exciting
and
frankly,
the
one
that
is
also
it's.
It's
not
it's
not
necessarily.
F
Like
this
is
our
sort
of
product
priority
board
right,
we
have
like
maybe
issues
that
need
to
be
like
validated
right
either
the
problem
needs
to
be
better
understood
or
the
solution
needs
to
be
understood
before
we
actually
feel
comfortable
scheduling
this
right,
and
so
this
is.
This
is
a
board
that
is
mainly
to
understand
sort
of
what
what
is
next
and
making
sure
that
we
don't
just
schedule
stuff
before
it's
ready,
so
on
a
regular
basis.
F
This
may
not
need
as
much
attention
in
in
the
engineering
call,
because
you
know
there's
sort
of
the
view
of
what's
ahead,
but
it's
not
exactly
what
we
need
to
do
right
now,
and
there
is
a
further
complication
that
I've
encountered
where
this
is,
I
think
easier
to
do
if
you
have
a
single
issue
right.
F
That
describes
a
feature
right,
a
very
encapsulated
thing,
but
often
I
prefer
working
with
epics
right
and
if
I
have,
if
we
have
validated
an
epic
right-
and
we
have
done
10
issues
inside
that
epic-
and
we
know
we
understand
the
epic
very
well,
I
don't
need
to
move
all
of
these
issues
through
here
right.
It
doesn't
make
any
sense.
F
We
just
know:
okay,
the
next
three
things
can
go
directly
to
the
billboard,
but
this
is
sort
of
the
more
product
planning
area
of
things
and
we
still
have
a
good
number
of
items
in
there,
usually
right,
because
sometimes
maybe
some
of
the
things
that
we
discussed
today
for
for
infra
right,
like
certain
features
or
things,
would
come
and
sort
of
be
moved
through
here
right,
that's
the
that's
another
board,
but
yeah.
That
is
what
that
is.
F
A
F
But
I
think,
for
now
the
triage
board
is
also
that's,
maybe
more
interesting,
because
that
may
be
something
that
the
team
will
interact
with
a
little
bit
more
and
so
the
way
we
we
thought
about
this.
It's
actually
kind
of
kind
of
neat.
I
think,
even
though
I
think
the
board
is
is
borked.
A
F
Okay,
that
makes
a
lot
more
more
sense,
so
I'll
just
start
with
one
here.
So
the
idea
that
janis
and
I
had
was
this
triage
label
essentially
gets
applied
to
anything,
and
it
could
be
anything
like
something
where
people
feel
this
is
like.
You
know
we
need
to
look
at
it.
You
know
it
may
be
something
that
the
database
group
actually
needs
to
investigate
or
not
right,
and
so
by
having
a
scoped
label
and
applying
it.
This
is
not
going
to
be
all
database
labels
right.
F
It's
a
small
subset
of
things
that
we
really
want
to
investigate
and
then
the
essentially
three
steps
to
the
decision
making
the
one
is
to
decide
like
do
I
want
to
close
it.
You
know.
Is
it
irrelevant?
You
can
do
that
right
here,
you
can
throw
it
out.
The
next
thing
is
to
say:
is
this
something
that
we
actually
should
look
into
right
as
in?
Is
it
something
that
really
belongs
into
group
database
and
that
we
can
then
go
into
this
column?
F
Here
you
can
pick
up
that
label
and
after
that
I
think
the
the
question
really
needs
to
be.
Is
this
something
that
we
need
to
work
on
right
now,
right
as
in
you
know,
is
it
a
bug
you
know
then,
or
is
it
a
priority?
Then
it
goes
to
database
active
or
is
it
something
that
we
need
to
validate
further
right
as
in
it
goes
into
the
planning
backlog?
F
F
F
It's
actually
gone,
so
you
can
clean
out
a
board
right
and
you
can
now
see
it
on
the
database
active
on
the
on
the
build
board.
F
Or
somewhere
I
may
have
lost
it
anyways
right,
it's
a.
I
think
it
doesn't
work
because
of
the
group
database
label,
but
in
essence
this
would
be
a
super,
simple
triaging
process.
Where
you
know
we
can
we,
whoever
in
the
team
you
know,
if
I
can.
F
A
C
Yeah
something
that
comes
to
mind
when
looking
at
the
build
board
is
sort
of-
and
this
is
perhaps
a
question
for
later
as
well.
It's
how
do
we
make?
How
do
we
keep
the
board
tidy
so
that
we
don't
end
up
having
like
a
gigantic
list
again,
but
basically
what
we?
What
we're
saying
is
we
put
the
active
label
on
things
that
we
we
sort
of
actively
care
about
or
that
are
ready
and
that
we
intend
to
pick
up
very
soon
correct
and
everything
else
doesn't
have
that
label.
So
no.
F
The
geo
billboard-
and
this
has
been
running
for
you
know
a
year
and
a
bit,
and
it's
a
larger
group
right,
so
there's
a
little
bit
more
stuff
going
on
here
right,
but
this
is
kind
of
how
this
looks
after
a
week.
So
we
have
you
know
a
bunch
of
stuff
here
in
in
review
right.
A
couple
of
things
closed
out.
F
F
Is
there
something
that
we're
just
shuffling
around
right
that
isn't
really
a
priority,
and
if
you
get
into
the
habit
of
doing
this,
it
becomes
really
sort
of
just
a
like
a
ritual
that
the
team
does
and
the
effect
this
has
had
on
the
on
the
geo
team.
Is
that
for,
like
people
go
to
this
column
here,
like
they're,
ready
for
development
item
right
and
say
I
have
nothing
to
do
anymore.
F
Let
me
check
what's
in
here
right
and
then
they
just
pick
something
and
go
next,
and
if
you
then
are
unsure
as
to
why
we
are
doing
it,
you
can
always
look
up
the
epic
ride,
and
here
the
epic
view
is
a
little
bit
more
sort
of
constrained
as
to
what
we
are.
What
we're
trying
to
do.
We
have
like
a
lot
of
work
in
maintenance
mode.
F
We
have
a
couple
of
sort
of
smallish
things
right,
but
many
things
are
in
in
epics
rather
than
in,
like
nothing
right,
and
that
is
where
you
kind
of
want
to
be
where
more
than
one
person
is
working
on
on
this.
A
F
No,
I
said
like
yeah
I
I
have
personally,
I
have
no
strong
feeling
on
with
limits.
I
would
argue
that
unless
you
know,
columns
really
flow
over
right
and
we
observe
that
consistently.
A
Nobody
knows
yeah.
I
found
that
in
other
companies
with
jira,
again,
okay
same
same
functionality,
there
was
a
lot
of
time
spent
talking
about
what's
the
whip
limit
and
it
didn't
provide
a
ton
of
value
yeah.
So
I
I
kind
of
agree
with
you:
it'd,
be
interesting
to
put
it
in
there
at
some
point
in
time
if
we
really
find
value
there,
but
yeah.
No,
this
is
this
is
great.
I
I
do
like
this
flow.
A
I've
used
it
before
in
other
companies
and
yeah
I'm
up
for
using
it
on
this
team
and
the
memory
team
actually,
but
we
can
schedule
that
later.
C
Question
about
the
label
itself:
there
is
also
a
database
group
label,
that's
being
used
all
over
the
place.
Basically,
whenever
something
is
related
to
database
is
the
scope
level
also
a
group
level,
and
if
yes,
does
it
not
conflict
with
the
not
with
the
preview,
with
the
existing
database
level?.
F
C
Well,
what
I
meant
is
look
at
the
first
issue
in
the
workflow
in
review
column.
It
has
the
database
level
of
blue.
This
is
the
one
that's
been
around
forever.
Basically,
everybody
applies
it
when
something
is
related
to
database,
and
then
we
have
the
scope
level
database,
the
active
triage
and
all
that
I
wonder
if
that
is
also
a
group
label
and
if
it
has
potential
to
cause
confusion
with,
for
others,
seeing
those
those
two
database
levels.
F
Maybe
I
would
maybe
say
that
the
database
active
thing
is
more
of
a
let's
say
internal.
You
know
to
to
us
and
for
our
group
process
as
how
we
manage
ourselves
so
we've
had
we've
had
this
in
geo
and
essentially
like
people
haven't
really
asked
right:
they
they
know
how
to
apply
the
other
labels,
and
this
is
just
another
thing
in
the
like
large
number
of
labels
that
we
maintain
so.
But
one
concern
that
I
had
but
janus
said
this
may
not
be
a
problem.
C
D
So
maybe
I
figured
out
why
we
lost
the
issue.
So
when
you
move
between
lists,
we
remove
the
label
of
the
previous
server
list
and
not
the
level
of
the
new
list.
So
moving
from
group
database
to
database
active,
it
remove,
remove
the
group
database
and
then
so
most
probably
the
way
we
are
setting
this.
F
F
I
think
we
can
give
it
a
try,
and
my
stance
on
process
is:
if
it's
not
useful,
it
should
be
eliminated,
and
so
luckily,
I
think
at
least
on
this
level,
we
have
a
lot
of
freedom
as
to
how
we
how
we
do
that
this
thing
has
the
advantage
that
it's
also
sort
of
90
compliant
with
the
official
product
development
workflow.
A
I
I
like
this
a
lot.
I
think
we
should
try
it
for
until
it
doesn't
work
anymore
right.
We
try
to
regularly
regularly
review
our
processes
anyway,
so
I
think
we
should
try
this
and
you
know
if
we
actually
get
the
approval
to
hire
more
people.
I
think
this
workflow
will
be
easier
to
use
for
a
larger
group
anyway.
So.
A
All
right
we
have
10
minutes
and
then
I
have
to
drop
for
sure.
There
are
a
couple
more
items,
so
giannis
you're
up
next
with
the
optional
label.
D
A
C
A
So
the
the
top
three
from
the
rice
framework
top
three
epics
were
three
indexing
primary
key,
the
migration
testing.
So
those
should
be
the
big
three.
Those
are
the
top
three.
If
it's
too
many
I
mean
we
only
have
three
team
members.
If
that's
spreading
us
too
thin
for
the
milestone,
then
let's
talk
about
that
in
the
planning
issue.
A
I
think
we're
gonna
have
to
go
async
on
planning
here,
but
if
reindexing
is
not
really
going
to
take
me
work,
how
much
work
do
we
think
the
primary
key
work
is
going
to
take
up,
and
should
we
focus
on
the
air
tables
that
are
up
next?
Because
if
it's
going
to
take
months
to
migrate,
we
should
probably
accelerate
our
work
on
the
other
tables
that
are
in
the
top.
Four,
I
think,
is
what
we're
looking
at
for
the
ones
that
are
great
to
go
into
overflow.
D
D
C
D
Work
over
920
million
and
a
second
the
table
that
is
600
million,
so
in
total
we're
going
to
go
over
1.5
billion
records.
Why?
I
think
that,
if
everyone
agrees,
I
would
propose
to
move
forward.
Events
add
also
the
helpers
for
the
events
for
the
final
finalizing,
and
maybe
we
can
start
with
the
next
table,
not
in
this
in
the
next
mission
into
milestones
from
now.
I
don't
know
if
I
have
one
agrees.
F
May
ask
a
really
quick
question
because
I
think
one
of
patrick's
concerns
was
that
we
work
on
too
many
things
in
parallel
and-
and
this
is
just
this-
is
always
the
the
issue
where
I
don't.
I
don't
know
how
easy
this
is,
but
if
we,
for
example,
for
for
our
prediction
for
13.9
focused
only
on
two
epics
right
plus
the
operational
like
bits,
the
primary
key
re-indexing
and
the
what's,
the
other
one,
the
migration
automatic
re-indexing
of
standard
stuff-
and
we
just
we
would
be
really.
F
Is
that
not
enough,
as
in
like
I'm
saying
like
if
we
really
said
like
okay,
we're
going
to
deliver
only
like
six
six
issues,
right,
we're
focusing
on
those
things,
and
maybe
you
know
this
is
going
to
take
us
two
weeks
and
we
have
a
continuous
flow
now.
At
that
point
we
can.
We
can
talk
about
and
say,
like
hey,
what's
next
right,
we're
running
out
of
work,
but
you
know,
then
we
can
eliminate
a
lot
of
these
other
things
from
from
the
board
and
we
just
focus
on
those
things.
First.
F
That
is
humes,
though,
and
this
is
my
my
question-
that
there
is
parallelizable
work
in
these
epics
as
in
you
can
do
more
than
two
things
at
the
same
time
you
know,
otherwise
that's
not
a
good
way
to
parallelize.
D
I'm
personally
super
excited
about
the
pro
testing
with
production.
If
I
had
to
vote
for
one,
I
know
that
we
have
priorities,
but
personally,
I
feel
that
this
is
the
most
exciting
and
it
also
aligns
with
our
rice
ranking.
D
So
as
long
as
yeah,
the
issue
for
indexing
is
not
going
to
take
a
lot
of
time
and
for
if
we
are
not
going
to
partition
to
address
more
tables
over
additional
to
the
events,
we
we
only
need
to
have
one
big
issue
on
the
primary
overflow
that
should
be
worked,
and
it's
working.
E
A
Using
this
example,
which
I
agree
with,
I
think
my
concern
for
39
is
there's
a
lot
of
work
in
flight
that
needs
to
be
finished
up
before
we
can
do
that
narrow
focus
right.
We
can't
just
drop
what
people
are
working
on
now
the
however
many
epics
we're
working
on
now
the
issues
that
are
in
flight,
so
wrapping
those
up
and
then
being
crisp
about.
Okay,
we're
just
working
on
these
two
things.
A
There's
the
consideration
for
the
operational
things
that
come
in
from
jose
and
jerry
that
require
our
immediate
attention
right.
So,
yes,
I
think
the
goal
is
to
get
there.
I
think
they're
just
some
things
that
we
need
to
clarify
that
are
in
flight
right
now
before
we
can
be
crisp
on
what
we're
doing
milestone
over
milestone.
F
We
can
essentially
say
if
this
is
still
all
correct
right
and
we
need
to
do
all
of
those
things.
Let's
say
we
will
and
then
anything
in
addition
to
that
is
from
the
two
epics
just
described
and
that's
it
and
then
you
know
we
go
from
there
because
I'm
always
a
little
bit
too
ambitious
and
I
skate
you
lots
of
things
and
then
half
of
them
are.
A
Agreed
I
do
have
to
drop
off
now,
so
I
well.
I
will
continue
my
input
on
the
planning
issue,
so
I'm
going
to
drop
off
thanks.
Everybody.
F
Yeah,
maybe
janice
you
can
you
can
collect
all
of
those
relevant
issues
from
the
two
epics
and
then
the
issues
that
are
still
outstanding.
And
then
we
can
put
that
in
the
planning
issue.
And
that
will
be
that.
C
Yeah
totally,
I
think
the
database
migration
testing-
it's
not
broken
down.
Well
enough.
I
think
so.
It
needs
more
thought
like
what
what
do
we
actually
want
to
do?
But
there
is
a
lot
of
work
in
there
that
can
be
parallelized.
I
think
going
back
to
fabian's
question
earlier
and
then
operational
issues
there's
a
bunch
anyway.
So
I
think
the
question
is
also
like
what
what
do
we
consider
taking
as
an
operational
issue?
This
is
kind
of
the
side
door
to
the
process,
but
we
can.
We
can
see
how
that
goes.
F
Yeah,
I
think
there
it's
important
to
be.
You
know,
that's
a
sort
of
the
defensive
art
of
not
committing
to
too
much
right.
There's,
probably
many
things
that
people
would
like,
but
there
there's
also
a
lot
of
things.
That
may
not
really
need
to
happen
right
now
right
and
we
need
to
be
careful.
Yeah,
yeah,.
D
So
I'm
going
to
update
the
planning
issue
and
I'm
going
to
update
the
epic
for
test
with
the
production
data,
because
it's
the
new
direction
should
be
different
than
what
we
had.
We
had.
We
said
last
week
that
we're
going
to
revisit
it
after
security
security
check.
I
think
that
we
should
update
it
either
way.
So
I
I
will
start
with
an
update
and
then
we
can
check
it
together
and
then
we
can
starting
for
the
next
issues
that
cannot
there
and
for
the
planning,
let's
add
the
epic.
D
A
D
Yeah
and
the
only
additional
thing
is
they're
finalizing
the
migration,
the
party,
the
migration
for
the
primary
keys.
F
Cool,
I
need
to
drop
off
as
well,
but
yeah
if
you
have
any
feedback
on
the
boards
or
anything
just
write
in
database
in
the
slack
channel
or
in
the
process
issue,
have
a
good.