►
From YouTube: Database Office Hours 2020-11-18
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
D
B
C
C
Of
showers
for
wednesday
18th
of
november,
I'm
going
to
share
my
screen
with
the
agenda.
C
C
You
anyone
want
to
talk
about
what
they
proposed
because
got
some
additional
proposals
on
reviews
etc,
or
should
we
take
it
offline.
A
Just
a
comment
I
was
having
a
similar
proposal
that
can
maybe
work
for
the
for
the
reviews.
Yeah
that
one
I
don't
know
don't
want
to
spend
too
much
time
on
it.
If
you
have
time
just
give
it
a
read,
it's
still
kind
of
fuzzy,
so
it's
not
entirely
worked
out
but
yeah.
E
C
D
E
Yeah,
what
happens
that
I
usually
ask
hey?
Is
anyone
else
using?
Usually
the
answer
is
like
no,
this
is
I
mean
if
it's
hey,
no,
it's
the
only
code
which
I'm
using
that's
fine.
You
can,
of
course,
search
for
it,
but
finder
finders
are
also
a
bit
difficult
in
that
you
know
they
are
building
up
a
query
in
runtime.
Sometimes
the
input
comes
from
the
user
interface
like
sorting
column
in
that
case,
there's
a
cloud
of
possibilities,
possible
queries
which
may
come
up
and
we
have
no
idea
which
one
is
affected,
particularly.
C
C
C
D
D
E
See
what
is
one
short
thing
about
query
performance?
I
when
I
like
one
year
ago,
I
reduced
it
from
10
seconds
or
whatever
in
the
document
to
one
second
actually
and
in
short,
shall
we
aspire.
E
C
I
think
that
the
fact
that
we
have
it
in
the
guidelines
is
a
good
start,
so
we
can
just
link
to
the
guidelines
and
the
guidelines
are
setting
the
rules
from
the.
C
Team
perspective,
I
can
tell
you
that
we
already
have
an
updatex.
We
are
already
measuring
the
performance
of
gitlab
against
the
100
milliseconds
and
the
50
milliseconds
for
github.com.
So
in
general
we
don't
want
to
have
queries
that
go
above
100
milliseconds.
There
are
always
exceptions,
so
we
can
leave
with
a
couple
of
exceptions
there,
but
it's
important
to
to
try
and
lower
execution
times
of
most,
if
not
all,
queries.
E
Yeah,
it's
very
good
result,
because,
one
year
ago
I
tried
to
push
it
under
one
second,
and
it
was
already
hard,
and
now
we
did
100
milliseconds
and
also
we
know
that,
like
on
any
screen,
we
should
have
less
than
100
queries
and
the
total
of
them
should
also
be
you
know
less
than
100
milliseconds.
So
it's
coming
to
an
interesting
point,
so
I
mean
let's
say
you
have
a
few
dozen
queries
on
a
page.
E
Apparently
most
of
them
are
simple,
selects
like
select
usernames
limit1,
but
there
might
be
one
or
two
like
search
queries
which
are
finding
a
set
of
records
or
a
list
of
records
they
are
allowed
to.
You
know
to
be
maybe
around
100,
milliseconds
or
less
than
100
seconds,
but
the
rest
should
be
even
like
less
than
10
milliseconds
hp,
which
is
always
true.
Writing
I
mean
single
object.
Finding
like
finding
a
single
row.
C
C
The
performance
of
git
lab
as
a
whole,
if
a
page
takes
three
seconds
to
load
because
there
are
queries
in
there.
There
are
10
queries,
it's
taking
500
milliseconds.
C
This
is
this
is
a
problem
and
we
should
try
to
not
to
increase
the
response
times.
So,
on
our
end,
what
we
can
do
is
keep
all
queries
as
low
as
possible.
E
Does
it
make
sense
to
ask
in
the
you
know,
ui
queries
the
authors
of
mrs
to
use
the
performance
bar
and
to
get
if
they
are
working
on
a
user
screen
and
to
get
a
list
of
the
queries
from
the
performance
bar
and
put
it
in
the
mr
description
at
some
point
so
that
we
know
like
we
slowly
built
every
screen.
C
Yeah,
this
is
a
food
for
thought.
That
would
be
great,
but
you
know
you
know
that
most
of
the
times
we
are
not
exposed
to
the
front-end
changes
to
the
controller
or
view
the
controller
changes.
So,
and
this
is
also
the
discussion
we
have
on
having
a
larger
mars
that
include
both
the
database
updates
and
the
application
code
update.
That
will
allow
us
to
see
things
like
that.
C
So
there
is
this
discussion
on
not
breaking
anymore
merged
requests
and
updates
multiple
metrics,
so
that
the
database
update
is
on
its
own
and
including
the
database
update
together
with
the
application
update,
so
that
the
database
reviewers
are
able
to
see
the
the
effect
of
the
update.
So
this
is
a
two
part,
so
we
will
be
able
to
understand
what
happens
there.
So
there
are
some
times
that
you
can
see
a
change
in
in
the
finder
or
a
table
added
and
you're
you
and
you
don't.
C
You
cannot
get
the
context
without
adding
checking
also
the
application
code,
and
the
second
part
is
what
we
are
saying.
If
you
can
see
the
controller,
for
example
or
the
model
you
can.
C
Also,
how
this
will
relate
to
other
parts
of
the
application
option.
D
A
C
Yeah
they
won't
affect,
they
won't
affect
the
initial
load
time.
So
asynchronous
requests
won't
affect,
for
example,
how
fast
the
page
will
load
so
from
let's
say
from
an
seo
perspective,
but
we
also
want
those
api
requests
to
not
take
10
seconds
so.
D
Right
yeah,
I
was
going
to
say.
Maybe
I
was
wondering
if
we
should
add
a
section
about,
like
you
know,
expectations
on
an
initial
load
time
versus
any
other
types
of
requests
that
occur
after
that.
That
could
be
helpful
when
it
when
we
are
dealing
with
like
an
entire
front-end
page,
that
we'd
want
to
look
at.
C
I
think
that
the
the
data
that
we
proposed
and
that
we
merged
covers
most
of
the
parts
on
our
side.
So
if
we
require
that
queries
that
are
participating,
api
responses
or
any
response,
don't
take
more
than
100
seconds
at
least
we
try
to
do
our
part
on
that
end.
So,
on
the
other
end,
if
there
is
a
loop
that
goes
and
and
runs,
100
queries
on
a
controller.
E
E
You
know
so
the
graphql
challenge
at
some
point,
maybe
also
something
which
will
increase
the
number
of
queries
on
front-end,
mrs,
which
will
be
hard
to
detect
so
you'll,
not
know
that
you
know
that
graphql
now
touches
20
queries
and
n,
plus
one
risks
and
and
it's
a
front-end
dmr
and
you
don't
even
you
know,
notice
that
there's
a
query
change.
So
that's
a
challenge
for
reviews,
just
something
if
any
ideas
there.
If
anyone
any
experiences
would
be
great.
A
Just
just
a
comment
we
already
facing
these
issues,
so
new
ur's
are
mostly
I've
seen
using
graphql
as
this
in
in
my
team,
and
it's
very
easy
to
write
and
plus
one
queries
and
chasing
them
down
and
solving
them
on
the
graphical
level
is
quite
challenging
and
what
I
seem
to
to
to
mitigate
this
is
introducing
costs.
So
each
node
that
you
are
looking
up
has
a
certain
cost
cost
and
and
within
one
request
you
can
basically
have
let's
say
maximum
10.
A
Well,
you
can
reach
maximum
10
costs
and
then,
after
that,
you
get
an
error.
So
we
have
some
sort
of
limits
we
can
set
up
based
on
the
complexity
of
the
graphql
query,
but
we
don't
don't
really
use
that
at
this
point
I've
seen
a
few
fields
already
having
this,
but
I
think
the
main
point
is
the
n
plus
one
queries,
because
you
can
load
up
each
merge
request
for
each
merge
request,
give
me
the
divs
the
d
files
or
the
div
stats,
and
that's
you
know
you
can
set
up
page
size.
200.
A
C
Great
government
adam,
thank
you
so
next
thing
to
discuss.
I.
E
C
To
bring
to
everyone's
attention
the
effort
to
test
with
production
data
for
anyone
not
knowing
about
that.
So
this
is
an
epic.
It
will
take
some
time
to
work
through
it,
so,
on
top
of
anything
else,
we're
doing
to
provide
access
to
database
maintainers
to
production
like
data
through
postgres,
ai,
we're
working
also
on
setting
up
servers
in
gcp,
so
that
we
can
run
migrations
there.
C
So
our
plan
at
the
moment
is
start
a
setup
once
in
the
server
that
will
allow
us
to
run
in
a
safe
and
safely
without
any
connections
to
the
outside
world.
C
It
won't
be
able
to
send
emails,
etc
to
run
migrations
for
any
brands,
and
our
plan
is
to
start
single
server,
create
an
image,
then
figure
out
a
way
to
provide
the
multi-user
server
to
all
maintainers,
and
the
idea
about
maintainers
is
that
all
database
maintainers
already
have
access
to
red
data
to
production
data.
So
we
don't
have
to
to
worry
about
other
issues
with
security,
etc,
and
once
that
step
is
done,
we
everyone
will
be
able
to
to
test
migrations
from
the
cloud
without.
C
And
then
we
will
have
to
think
about
how
we
can
automate
that,
and
there
are
two
possible
way
roads
there.
One
path
is
to
anonymize
production
data,
so
why?
When
we
create
those
thin
clones
also
anonymize
the
data.
C
But
that
means
that
we
will
have
to
to
put
the
effort
to
mark
the
pii
information,
the
columns
that
we
will
have
to
analyze
and
and
then
anonymize
the
data.
So
that
means
that
we
will
have
a
clone
with
anonymized
data,
so
we
will
be
able
to
maybe
provide
that
clone
access
to
more
people
that
don't
have
access
to
the
data
and
another
path
is
maybe
setting
up
in
the
future
private
runner.
That
will
be
able
to
run
ci
tests
against
production
data
and,
depending
on
whether
we
are
using
a
minimized
data
or
not.
C
Maybe
we
don't
return
any.
We
don't
have
any
laws
in
the
job,
but
at
least
we
make
our
lives
easy.
So
the
common
case
will
be
the
test.
D
B
B
Yeah,
in
my
experience,
I've
we
tried
to
analyze
data
before
and
and
as
far
as
I
can
tell,
it
was
not
easy
to
do
that
like
in
a
reliable
way
that
also
that
the
data
also
still
makes
sense,
because
you
could
just
remove
all
descriptions
from
issues,
for
example,
to
to
to
some
fixed
words,
but
then
you
get,
then
you
get
no
longer
the
random
data.
You
have
from
a
regular
database
so
and
then
yeah,
you
have
to
be
sure,
you're
anonymizing
everything.
B
I'm
also
not
sure.
If
you
want
to
how
we
want
to
keep
that
database
like
up
to
date
with
the
schema,
because
would
we
would
you
be
doing
the
production
database
re-analyzing
over
and
over
again,
or
will
we
run
migrations
on
that
database
to
keep
it
in
sync
yeah?
I
see
a
lot
of
things
that
can
go
wrong
with
that.
C
I
totally
agree
and
we
have
more
than
300
tables,
so
even
marking
the
the
columns
that
need
anonymization
is
a
huge
task.
Then
we
would
have
to
set
the
process
in
all
database
reviews
for
any
new
table
in
any
new
column,
to
go
through
security
review
and
and
also
there
are
all
the
other
problems
like.
We
have
json
data
and
we
don't
want
to
destroy
the
jsonp
data.
So
what
happens?
C
The
second
part
that
worries
me
also
with
anonymization
in,
is
that
you
mess
with
data.
So
you
change
how
indexes
work,
if
you
anonymize
names
and
emails
or
whatever
else
the
behavior
of
the
index
is
changed,
you
don't
have
any
more
the
same
data
in
production
and
I
don't
know
what
the
consequences
are
and
also
you
add,
a
layer
of
another
layer
between
you
and
your
production
data.
So.
C
Against
the
anonymization
process,
so
if
the
anonymization
process
has
bugs
you
test
against
those
sort
of
bugs
but
yeah,
this
is
an
open
discussion.
Please,
if
you
have
any
comments,
the
the.
C
C
A
C
Database
them,
if
you
have
any
additional
comments
there,
the
idea
is
creating
a
database
game
that
will
be
reside
outside
of
the
the
core
repository.
E
D
E
We
had
discussed
it's
too
early
and
also
that's
the
initially
she
linked
there.
It
makes
a
lot
of
sense,
especially
the
versions,
app
customers,
dot
app
license
data
where
I'm
also
working.
We
sometimes
need
same
challenges
and
we
just
copy
the
actual
version
of
the
s.
Certain
database
helper
from
gitlab
code
and
it's
becoming
tedious,
would
be
great.
E
One
problem
will
be
the
you
know,
so
we
have
a
little
specific
utilities
and
some
generic,
so
we
may
move.
I
think
the
postgres
specific
to
a
certain
gem,
or
we
may
just
have
a
generic.
I
mean
my
question
is:
do
you
want
to
contribute
to
the
open
source
community?
In
that
case,
we
have
to
think
differently
in
packaging
the
gems.
In
that
case,
we
may
need
two
or
three
gems,
but
if
we
just
want
to
have
something
like
a
gitlab
gem,
that
will
be
great.
E
The
only
risk
I
see
there
is
that
the
licensed
versions,
customers
and
some
other
applications
are
running
on
version
9,
10
11
of
postgres.
So
that
will
be
a
challenge.
C
C
C
F
Hello,
everyone
first
time
we're
here
so
one
well,
I
I
have
this
issue
that
I'm
working
on
and
it's
not
even
close
to
the
verification
step
yet,
but
I
just
want
to
make
sure
that
I
have
something
like
to
be
able
to
do
it
when
it's
it's
time
and
I'm
wondering
like
if
there
is
any
specific
or
accepted
approach
to
verify
self-managed
changes.
When
you
know
you
are
concerned
about
any
database
performance
issues.
F
If
there
is
not
enough
data,
you
know
like
locally
there's
no
problem,
there's
no
issue
because
obviously
there's
not
enough
data
in
you
know
my
local
or
self-managed
different
installation
that
I
have
so.
F
I
was
wondering
if
there
is
something
that
it's
like
like
you
do
or
if
we
just
you
know,
turn
the
put
your
flag
on
in
getlab.com
and
then
try
it
on
them
or
yeah
like
if
it's
just
enough
to
do
it
like
on
the
staging,
which
I
know
doesn't
have
like
a
lot
of
data
like
gitlab.com
does
but
yeah
like
just
wondering
how
do
you
approach
a
new
scenario
like.
C
C
F
That
is
the
idea
because
it
will
block
a
new
user
signup.
So
it's
a
new
configuration,
so
I
don't
think
we
want
to
do
that
like
on
gitlab.com.
I
think
we
should
add
actually
like
the
dot
com
check
to
not
do
it
on
the
comp.
So
yeah,
then,
if
that
is
not
like
available
in
dot
com,
how
would
I
go
about?
You
know
verifying
the
change.
E
So
actually
our
databases
schema
is
common
on
core
edition
c
edition,
enterprise
edition,
self-finished
and
github.com,
so
that
first
of
all
gives
makes
keyclap.com
a
very
good
example
for
every
other
instance.
E
Secondly,
when
I
had
the
check
on
different
self-managed
instances,
the
largest
self-finished
instances,
which
we
could
get
usage
ping
had
15
times
less
users
than
gitlab.com
and
35
times
less
cie
builds
and
like
30
40
times
less
issues.
So
I
checked
issues,
ci
bills,
ci
and
the
users
as
examples.
So
what
I
believe
is
that
any
query
or
any
code
which
runs
good
in
gitlab.com
and
github.com,
is
very
challenging
actually
and
sometimes
too
challenging
will
run
on
particularly
self-managed.
Instances.
Second
thing
is
that
omnibus
installations
have
some
more
relaxed.
E
B
Okay,
but
one
question
though
okay,
so
our
database
is
like
a
lot
larger,
but
compared
to
customers.
Do
we
have
better
infrastructure
structure,
better
processors
for
the
database,
instances
compared
to
those
machines,
or
even
like
having
databases
running
on
on
on
hard
disks
instead
of
ssds
and
stuff,
like.
E
That
I
totally
think
we
have,
I
was
able
to
check
three
or
four
customer
installations,
and
they
really
have
even
the
best
customers
have
a
bit
less
than
you
know
what
we
have
a
lot.
C
Less,
I
think
that
the.
A
C
A
very
nice
dashboard
in
periscope
with
data
from
self-hosted
instances,
so
that
you,
the
the
user
data
and
you
can
check
memory
cpus
and
everything.
C
C
F
Okay,
I
think
that
that
sounds
good.
Just
another
thing
that
okay,
when
so,
do
you
think
it's
it's
then
not
necessary
to
have
like
the
don't
run
this
on
dot
com
or
just
run
the
the
long
query
in
this
case
manually
by
a
maintainer
like
in
that
case,
would
I
be
just
verifying
that
the
query
does
not
run
long
enough
that
my
process?
C
Yeah,
so
so,
if
the
the
the
difficult
part
there,
the
expensive
part
is
a
query.
A
C
Can
you
can
test
against
production
data
using
the
database
labs?
So
if
the
only
concern
there
is
the
query
you
you
can
also
do
that.
Follow
the
guidelines
on
testing
queries
and
you
can
you
can
use
database
labs
and
also
involve
a
database
reviewer
and
maintainer.
If
you
need
additional
text,
if
there
are
additional
parts
of
my
of
the
update,
that
means
the
verification.
F
E
F
E
E
I
will
find
out
I've
benefited
from
some
other
examples
which
are
using
bulk
insert
to
generate
like
10
million
of
some.
You
know
rows.
E
C
F
C
Yeah,
but
we
cover
only
I,
if
I
recall
correctly,
25
or
tables,
and
we
feel
I
think
we
feel
a
lot
of
data
on
you
for
20
of
those
like
issues
users.
C
So
we
have
this
and
you
you
can
generate
in
a
local
environment
with
a
lot
of
data,
but
it
will
be
lots
of
data
artificially
generated
data
for
projects,
issues,
notes
comments
and
that
kind
of
stuff.
If
what
you
want
to
test
is
not
on
those
20
core
entities,
then
you're
out
of
luck.
There.
F
Okay,
okay,
one
follow-up
question
on
database
lab:
I'm
not
sure
if
this
is
known.
How
long
does
it
take
for
a
new
index
to
be
applied
to
what
we
use
on
database
lab
because
I've
seen
yeah?
It's
it's
been.
I
think,
like
four
days
since
an
index
that
I
was
thinking
was,
there
was
not
there.
So
I'm
not
sure.
Well,
I
haven't
really
checked
today,
but
I
checked
yesterday
and
it
wasn't
there.
It
was
not
my
index,
it
was
actually
worked
by
someone
else,
but
I
was
hoping
it
was
there
when.
F
C
Okay,
we
have
an
issue
right
now.
The
data
database
labs
is
a
little
bit
lagging
with
respect
to
production.
In
general,
you
should
be
able
to
see
production
updates
in
in
a
day.
I'm.
C
But
there
is
an
issue
and
I
know
because
I've
seen
somewhere
in
a
comment-
and
I
checked
so
we
are
lagging
behind
production
at
the
moment.
If
you
don't
mind
other
comment
in
the
the
database.
F
C
B
A
C
Remember
that
everything
that
you
do
in
database
lab
is
for
the
duration
of
your
session.
So.