►
From YouTube: Workspaces database sync 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
Okay,
so
hi
everyone
we're
meeting
to
discuss
the
problems
with
backfilling
migration,
which
is
the
part
of
workspace
project
as
we
get
the
feedback
from
database
team.
That's.
This
is
probably
not
the
best
idea
and
we
need
to
think
about
some
better
strategies
to
to
develop
this
feature.
So
we
provided
a
little
bit
of
context.
I
think
imra
orianna
are
the
best
people
to
provide
too
long
didn't
read
a
version
of
why
we
are
making
these
changes.
B
Sure
I
can
go
a
quick
summary,
so
basically,
the
problem
today
is
we
have
multiple
containers,
groups
and
projects
and
when
a
feature
is
implemented,
it's
implemented
in
one
of
those
container
levels,
but
there
have
been
like
many
requests
in
the
past
to
make
the
feature
available
on
another
level
which
resulted
in
the
re-implementation
of
the
feature
with
slight
change.
B
So
this
leads
to
code,
duplication
and
basically
diverging
features.
So
the
solution
we
came
up
with
is
to
wrap
everything
with
the
namespace
because
we
currently
have
so.
Our
groups
are
basically
namespaces.
B
The
personal
namespaces
are
also
named
spaces,
and
we
want
to
like
introduce
project
namespace,
to
wrap
around
project,
and
this
would
allow
us
to
have
a
single
container,
the
namespace
as
a
container
for
features.
So
when
we
want
to
make
a
feature
available
on
some
other
level,
we
just
need
to
like
make
sure
it's
available
on
namespace,
and
then
it
will
be
available
on
groups,
personal
name,
spaces
and
projects
as
well.
B
So
that's,
basically
the
the
reason
behind
the
the
whole
idea.
B
Yes,
a
container
as
as
a
container
for
for
a
feature.
So
as
the
example
here
is
groups
projects
and
and
personal
namespaces,
I
just
use
the
container
as
some
some
generic
term
to
to
to
have
the
feature
available
somewhere.
C
So
right
now
these
the
we
already
share
code
between
them
right.
We
have
concerns,
we
have
concerns
mainly
but
right
and
I'm
I'm
guess,
I'm
wondering
what
we
get
out
of
combining
the
data
storage
back
in
as
opposed
to
just
making
these
two
models
be
effectively
identical
and
then
just
sharing
all
of
their
code
through
concerns.
B
Yes,
so
they
are
far
from
being
identical.
There
are
many
differences
and
when,
for
example,
a
feature
is
available
made
available
by
a
concert,
this
was
also
like
discussed
in
the
past.
The
problem
is,
it
also
needs
to
like
deal
with
the
differences
between
projects
and
groups.
C
I
guess
I
I'm
still
I'm
still.
Maybe
I
maybe
I'm
missing
something,
but
I'm
trying
to
understand
you,
you
don't
you
still
have
to
make
them
be
the
same
in
order
for
them
to
share
this
data
back
end
right,
like
they
have
to
we're
we're
trading.
One
piece
of
complexity
for
another
right,
like
projects
and
namespaces,
are
different
right.
Unless
we
plan
on
having
namespaces
have
code
repositories
right,
like
they'll,
still
be
different
conceptually
at
the
end
of
the
day.
B
Yeah
so,
for
example,
as
for
projects,
we
want
to
like
get
them
get
basically
like
all
features,
get
rid
of
them
and
basically
want
to
like
have
projects
basically
as
a
as
a
wrapper
around
repository,
so
we
want
to
like
have
a
single
entity,
so
I
think
it's
like
very
close
to
like
unifying
the
two.
It's
just.
C
Sorry,
my
headphones
have
been
kicking
in
and
out.
So
hopefully
you
can
still
hear
me,
but
I
guess
I
I'm
still
trying
to,
and
maybe
someone
else
on
the
database
team
could
kick
in
here
and
it'd
be
like
alex
you're,
crazy
or
something,
but
I'm
just
trying
to
understand
why
they
need
to
be
in
the
same
database
tables.
C
C
A
database
table
layer
in
a
different
way
right,
like
we've
already
got
they've
already
got
to
have
right,
like
the
ones
with
projects
still
have
to
be
related
to
their
project,
object
so,
and
we're
already
going
to
have
to
look
up
things
that
are
just
projects
pretty
regularly,
and
I
guess
I
I
I'm
not
sure
where
combining
the
tables
is
the
absolute
requirement
here.
It
feels
like
a
convenience.
E
Alex
we're
not
really
combining
the
tables,
the
project
table
will
continue
to
be
itself
and
the
namespace
table
will
continue
to
be
itself,
those
aren't
being
combined.
What
we're
doing
is
we're
moving.
What
would
typically
be
a
feature,
such
as
issues
from
a
project
object
up
into
its
container
object,
so
now
a
container
will
be
able
to
have
a
project
issues.
E
Any
other
features
that
we
add.
That
will
be
the
central
point
instead
of
being
a
project,
and
that
means
we'll
be
able
to
operate
on
name
spaces
themselves
in
a
much
more
efficient
way,
rather
than
for
permissions,
etc.
Rather
than
querying
a
separate
project,
job
object
and
all
that
stuff,
so
we'll
be
able
to
combine
moving
all
the
authorizations
up
into
the
container
moving
the
features
such
as
issues
up
into
the
namespace
level,
which
is
already
there
for
groups
we're
just
adding
a
project
namespace
to
also
contain
those
features.
C
D
Yeah,
so
that
idea
makes
sense
to
me:
I'm
still,
you
know,
concerned
about
how
much
this
is
going
to
grow
the
size
of
the
name
spaces
table.
I
don't
have
a
solution
for
that
off
the
top
of
my
head,
but
it
is
by
far
my
my
primary
concern
because
it'll
grow
it
by.
I
feel,
like
I
read
about
60
somewhere,
I
might
be
missing
that,
and
also
because
it
you
know
we
have
documentation
that
says
that
we
should
avoid
single
table
inheritance.
Whenever
we
can
do.
A
They,
like
our
idea,
is
that
they
would
not
need
different
fields
because,
like
for
example,
settings
they
can
go
to
the
namespace
settings
table.
So
the
idea
is,
we
are
not
going
to
provide
more
more
columns
to
namespace
table.
That's
that
would
be
like
opposite
of
what
we
are
trying
to
achieve.
D
Yeah
no
problem-
that
was
my
main
question
and
basically
I'm
I'm
concerned
about
using
single
table
inheritance,
our
documentation,
sort
of
says
that
that's
generally
not
a
good
idea
and
it
it's
kind
of
an
odd
access
path
for
the
database.
D
But
if
you
aren't
creating
many
additional
columns
just
to
support
one
of
your
single
table
inheritance
classes,
then
it's
not
as
big
of
a
deal.
F
And
it's
foreign
it's
for
transitional
period.
Only
so.
Basically,
this
new
sort
of
different
name
spaces
eventually
should
become
not
just
namespace
and
we
will
probably
not
be
able
to
drop
the
type
column
in
the
future.
Just
because
we
have
the
user
name
spaces
that
are
slightly
different,
but
we
can
drop
the.
I
guess
we
can
drop
the
single
table
inheritance
so
to
say
so.
We
can
have
some
some.
F
If
statements
just
to
treat
slightly
different,
this
username
space,
we
don't
necessarily
have
to
have
the
single
table
inheritance
model
within
within
rails.
So
that's
that's
that,
but
it's
going
to
be
quite
a
longish
way
to
get
there.
I
would
assume,
because
we
need
to
migrate,
like
basically,
the
entire
application
needs
to
move
from
project
into
project
namespace,
and
that's
the
moment
when
we
basically
can
remove
the
single
table.
F
Inheritance
thing,
the
single
terrible
inheritance
kind
of
gives
us
this
stepping
stone
to
move
things
into
many
spaces,
well
still
being
able
to
differentiate
like
which
things
move
into
namespaces,
but
need
to
be
treated
slightly
different
for
the
meantime
until
we
kind
of
move
them
to
the
name
space
itself.
F
So
if
we
could
have
like,
because
there
is
too
much
complexity,
we
could
not
really
take
a
feature
from
project
and
move
it
right
into
the
name
space
and
be
sure
that
everything
just
works
like
we
need
to
do
it
incrementally
and
yeah.
That's
like
if
we
would
have
not
had
this
big
application
with
lots
of
users,
it
would
have
been
much
easier
to
just
take
and
move
and
and
be
solved
with
it,
but
because
we
need
to
make
sure
that
we
don't
break
things.
F
Maintain
compatibility,
announce
users
that
some
features
will
now
become
available
at
the
name
space
or
and
so
on.
We
kind
of
have
to
do
this.
I
don't
know
if
there
are
any
other
ideas.
That
might
be
that
we
need
to
analyze
and
sort
of
like
to
skip
that,
but
I
I
think
it
was
discussed
quite
vastly
and
the
other
option
was
to
move
the
other
way
around,
of
taking
namespaces
into
the
project.
Stable
sort
of
thing
where
you
kind
of.
F
F
And
that
that
becomes
the
container
so
like
a
couple
of
these
options
were
discussed
during
blueprint
architecture
and
on
the
whole
thinking
behind
this,
because
this
has
been
now
for
over
a
year.
I
think,
if
not
more
going
back
and
forth
analyzing
discussing
like
I
do
agree
that
there
is
a
worry
about
growing
this
namespaces
table
and
my
main
concern
with
that
will
be
not
the
back
feeling
itself
right
now.
We
can
do
it
as
slow
as
we
need
to
it's
really.
F
What
comes
after
that
in
the
phase
two
and
so
on,
when
we
start
using
where
yeah
so
start,
adding
a
lot
of
features
to
the
name
spaces.
But
I
guess
that's
again
something
that
kind
of
goes
through
our
usual
deployment
and
feature
development,
where
you
move
something
behind
the
feature
flag,
make
sure
that
nothing
breaks,
make
sure
that
the
traffic
and
so
on
and
so
forth.
I
don't.
F
I
don't
know
that
anyone
can
guarantee
that,
like
mistakes
are
yet
to
be
done
but
yeah
this
is,
I
think,
the
back
feeling
itself
is
not
the
issue,
at
least
from
my
perspective
and
adding
these
roles.
It's
what
comes
afterwards
with
the
feature
virtualization
and
and
what
queries
we
will
be
adding
afterwards,
because
right
now,
these
fields
are
these
records
are
added
and
are
basically
just
donglers
in
the
namespaces
table.
Those
are
not
exactly
used
yet
until
we
start
doing
the
phase
two
and
merging
some
some
new
code
into
that.
D
Do
you
expect
to
have
significantly
different
patterns
of
updates
on
this
table
once
you've
made
this
change.
F
No,
not
that
not
that
I'd
be
aware
of.
I
don't
think
there
is
much
different
on
the
table
itself,
but
there
are
things
that
will
change
around
the
table
and
and
like,
like
memberships,
will
be
joining
with
this
table
now.
F
I
guess
more
than
it
used
to
be
because,
like
all
of
the
projects,
members
would
move
into
sort
of
using
the
namespaces
now
the
routes
and
all
of
these,
like
things
that
used
to
go
both
to
projects
and
namespaces
now,
will
only
start
to
go
mainly
to
the
namespaces
and
that's
not
the
near
future,
either.
It's
like
something
into
medium
to
long
term.
I
think.
D
F
Like
I
have
a
kind
of
a
question
on
the
contrary
or
on
the
opposite,
like
let's
say,
because
we
want
gitlab
to
grow
right,
so
what
happens
if,
in
a
year
we
grow
the
namespaces
table
just
naturally
twice
or
three
times
or
five
times
as
big
as
it
is
now?
How
do
we
handle
that
situation?
In
that
case,
and
and
if
we
can
answer
that
question,
then
that's
something
that
we
can
apply
here
I
mean.
F
An
interpretation
this
table
in
one
way
or
another
or
come
up
with
some
solution
to
kind
of
make
it
scalable,
but,
like
I
I
again,
maybe
you
can
apply
that
kind
of
thought
process
into
this
and
see
how
we
can.
How
do
we
handle
a
5x
or
10x
or
3x
growth
on
the
overall
application
right.
D
Yeah,
I
think
that's
a
very
good
point.
I
think
the
only
way
we
could
handle
growth
like
that
is
to
partition
the
table,
probably
by
the
top
level
namespace
id,
although
there
are
other
options
and
that's
something
that
the
database
team
is
thinking
about,
we're
thinking
about
keeping
all
of
our
tables
below
100
gigabytes.
But
we
don't
have
capacity
to
work
on
that
yet,
but
that's
definitely
something
that
we
should
consider
in
like.
While
we're
also
doing
this
alex.
F
It
a
problem
to
to
partition
by
root
namespace,
given
that
we
have
this
feature
of
moving
a
root
namespace
as
a
subgroup.
Basically,
so,
basically,
what
that
means
to
me
is
that
a
lot
of
this
data
will
need
to
be
moved
to
a
different
partition
in
some
scenarios.
So
I
don't
know
if
that's
something
that
database
or
postgres
can
handle
on
its
own,
or
we
need
to
do
a
lot
of
these
weird
migrations
of
replacing
ids
and
all
that
coordination
thing.
D
D
G
D
Yes,
the
way
that
it
would
have
to
be
done
is
to
create
a
new
table
that
is
partitioned,
fill
all
of
the
data
across
and
then
rename
the
table
and
do
a
swap.
We
did
this
to
the
events
table.
For
example,
I
started
the
webhook
logs
table,
for
example,.
D
E
What
one
of
my
concerns
about
partitioning
now
is
the
additional
complexity
of
it,
because
we're
basically
in
order
to
do
that,
we
basically
need
to
stop
our
line
of
work,
partition
the
namespace
table
and
adjust
all
queries,
everything
and
and
ship
that
before
we
can
continue
with
our
other
work.
So
this
basically
stops
this.
This
line
of
development
at
the
moment,
whereas
and
and
is
actually
more
complex,
because
our
queries
span,
the
name
spaces
and
the
projects
in
a
lot
of
places.
E
C
I
think
I
think
you're,
not
I
I
I
think
you're
maybe
not
wrong.
I
guess
my
our
my
counterpoint
to
that
is
what
happens,
but
is
our
I
think,
we're
concerned
about
what
happens
if
it
turns
out
that
this
is
too
much
for
the
namespaces
table
as
it
is,
and
it
we
see
partitioning
as
a
safety
thing
in
this
case
right.
E
E
C
C
That's
a
hard
limit
too
so
like
when
we,
if
we
hit
100
gigabytes
with
a
table.
That
means
that
we
have
that
that
to
our
team
means
that
we've
already
failed,
because
that
table
has
already
hit
a
point
where
it
is
like
that
that
is
a
like
extremely
high
priority
change
at
that
point,
right
we
and-
and
we
have
not
enforced
this
particularly
well
right
and
we
have
a
bunch
of
tables
that
are
over
100
gigabytes
and
we
really
have
to
try
and
get
them
broken
up,
but
going
forward.
E
I
absolutely
completely
agree,
but
but
if
we're
at
10
gigabytes
then
growing
to
15
or
16
for
a
trans,
you
know
until
we
can
get
this
solved
and
then
move
forward
with
the
partitioning
at
the
30
gigabyte
level.
Eventually
or
before
that
might
be
a
safer
route.
It
seems
like
and
the
database
should
still
be
able
to
handle
that
right.
D
F
I
was
wondering
one
other
thing:
can
we
make
a
partition
by
type
fill
in
all
of
these
project
namespaces
in
that
new
partition
and
kind
of
give
it
a
try?
Would
that
be?
F
I
guess
it's
not
the
same
thing
as
as
migrating
into
directly
into
the
namespaces
table,
but
like
what
I
was
like
have
that
partition
see
how
the
application
behaves,
because
you
can
easily
detach
the
partition
if
anything
goes
wrong,
right
and
and
basically
say
well
here
you
go.
We
proved
that
it's
not
it's
not
worth
doing
but
beyond.
If
that's,
okay,
then
kind
of
backfill
it
into
the
namespaces
table
itself,
but
I'm
not
sure
if
that's
a
good
idea
at
all.
F
A
Is
it
like
exactly
the
opposite
of
what
partition
should
look
like
because
like
if
we
have
all
the
projects
in
the
project
namespaces
in
one
partition,
and
we
want
to
query
all
the
namespaces,
this
will
be
the
opposite
of
what
partitioning
is
supposed
to
do
in
order
to
be
more
effective?
D
Yes,
because
all
of
the
queries
will
have
to
cross
partitions
to
find
the
projects
that
are
at
the
bottom
of
the
tree.
I
I
think,
is
what
you
mean.
F
The
ones
just
the
ones
that
need
to
build
the
hierarchy,
I
guess
completely
and
include
both
the
namespace
and
the
project
namespace
records
if
you're
only
addressing
like.
If
you
are
referring
to
the
so
say
you
fetch
a
project
and
you
need
its
project
name
space.
It
will
only
look
up
the
the
the
partition
with
the
namespaces
and
the
other
way
around.
F
If
you,
if
you
fetch
the
name,
the
project
namespace,
to
look
up
the
project,
it
will
only
look
into
that
partition,
but
then
I'm
not
sure
how
similar
that
is
to
actually
having
the
records
in
the
names
spaces
table
itself.
I
guess
it's
the
same.
If
you
have
the
index
by
by
type
right,
it's
some
somewhere
similar.
F
D
It's
a
it's
a
big
change
when
it
comes
to
something
that
we're
worried
about
which
is
vacuuming
times
so
vacuuming
times
for
the
table
are
proportional
to
how
big
the
table
is
and
partitions
are
vacuumed
separately.
So
we
wouldn't
see,
we
wouldn't
see
the
problem
that
we're
worried
about.
If
we
had
this
test.
Okay-
and
also,
I
would
say
that
any
query
where
you
could
exploit
this
partitioning
by
type.
D
You
could
just
write,
I
feel
like
you-
could
just
rewrite
each
one
of
those
queries
slightly
to
use
the
two
tables
or
to
use
or
with
a
union
or
a
join.
So
I
don't.
I
don't.
I
might
be
wrong.
I
am
not
as
familiar
with
this
feature
as
you
are,
but
I
don't
really
see
where
it
would
make
a
huge
difference.
G
I
hope
I'm
not
changing
to
pick
too
much,
but
I
was
wondering
so
from
the
previous
sync
up
call.
My
understanding
was
that
there
is
a
generic
concern
about
backfilling,
which
is
mainly
about.
We
are
growing
table
too
much
so,
based
on
this
sync
up,
we
agreed
to
do
some
performance
testing
by
testing
how
our
application
would
behave
with
after
backfilling
this.
G
So
now,
based
on
these
results,
can
we
can
we
do
some
outcomes
from
this
testing
like
like
proving
okay,
so
based
on
these
results,
it's
really
a
concern
and
we
should
be
worried
about
doubling
the
doubling
the
table
or
is
there
some
specific,
more
specific
concerns
we
have?
G
C
I
think
for
me
my
my
concern.
Taking
away
from
the
testing
was
not
necessarily
the
results.
The
results
in
in
general
seemed
reasonable.
I
was
worried
more
about
the
scale
like
and
realistically,
we've
run
into
this
kind
of
time
and
time
again.
The
gitlab.com
scale
is
just
so
much
bigger
than
we
expect
and
the
database
behaves
differently.
We
run
into
postgres
bugs
we
run
into
all
sorts
of
stuff
when
we
hit
that
scale
right,
like
the
other
day,
a
team
tried
to
delete
a
bunch
of
stuff
and
it
took
down
our
database
right
like
well.
C
G
G
Reason
we
were
asking
for
environment
as
close
as
possible
to
production,
which
I
understand
is
hard
too
hard
to
do,
but
I
wonder
what
we
can
do
about
that,
because
it
seems
to
me
that
we
might
actually
halt
or
invest
half
of
a
year
to
different
work
just
because
of
a
generic
concern
without
specific.
If
I
was
formulating
specifically,
what
exactly
is
the
problem?
You
should
focus.
F
So
can
we,
I
don't
know,
do
we
need
to
because
I
think
we're
close
to
time.
Do
we
need
office
hours
or
do
we
need
to
continue
to
discuss
it
like
we
need
to
decide
how
we
want
to
proceed?
I
I
wan.
I
was
wondering
like
I.
If
we
can
do
the
migration
and
on
blog
phase
two,
but
at
the
same
time
kind
of
think
what
nothing
but
work
actively
on
on
doing
the
partitioning
by
root
name
space.
That
is
one
path
forward.
F
Right,
we're
not
blocking
we're,
not
stopping
here
or
maybe
are
some
other
ideas
how
we
can
move
or
maybe
there
is
a
no,
we
cannot
move
forward.
We
cannot
do
that.
Let's
put
a
hard
stop,
so
we
need
some
kind
of
resolution.
Maybe.
A
F
The
closest
future,
so
that
we
know
how
we
need
to
restructure
the
countryside,
they
whatever
we
need
to
work
on
next
right.
Maybe
we
need
to
stop
the
phase
two
completely
and
phase
one
inclusively
and
just
work
on
the
partitioning
and
and
see
how
that
works
out
and
undo
that
first
and
then
move
backward.
Maybe
we
can
do
the
by
like
the
migration
and
then
afterwards
working
parallel
on
phase
two
and
the
partitioning.