►
Description
Part 1: https://www.youtube.com/watch?v=MiZFtM84x44
Part 2: https://www.youtube.com/watch?v=nt4Khi9Gr3o&feature=youtu.be
Part 3: https://youtu.be/ztQtNmSYmEo
A
So
in
the
previous
demos,
we've
seen
how
to
create
partitions,
we've
created,
charts
using
local
databases,
and
then
we
pushed
out
the
data
for
those
petitions
to
the
charts.
It
was
part
1
and
part
2.
We
looked
at
schema
migration.
So
how
do
you
deal
with
adding
or
dropping
a
column
with
those
charts
present
and
now
in
this
demo?
We
look
at
how
to
deal
with
titles
to
be
calls
reference
tables.
So
how
do
you
deal
with
tables
that
you
can't
chart,
or
you
won't
you
don't
want
to
chart?
A
A
We
can't
go
to
the
Chardon
and
do
and
run
queries
that
touch
the
issues
table
and
then
join
the
users
table,
for
example,
and
assuming
that
we
can't
chart
uses
table
in
a
similar
fashion,
and
perhaps
we
you
might
want
to
have
that
as
a
reference
table
on
the
chart
as
well.
So
what
we
can
do
here
is
apply.
Our
logical
replication
basically
replicate
the
user's
table
from
the
main
database
into
into
the
shark
database.
How
does
that
work?
We
go
to
the
main
database
and
then
we
basically
set
up
logical
replication.
A
A
A
Basically,
specifying
the
main
database
connection
string,
so
this
is
my
local
database
since
it's
the
main
database
using
the
publication
of
it
is
created
and
using
the
logical
replication
table.
We
created
this
a
workaround
or,
if
you
admit
those
it's
not
going
to
work
if
they,
if
the
replication
source
is
on
the
same
local
database,
because
it
sort
of
hangs
in
that
situation,
and
then
you
resolve
that
by
by
creating
the
replication,
so
the
head
of
time
and
I'm
telling
him
not
to
create
a
slot
in
this
thing.
A
At
the
same
time,
it
creates
the
subscription,
and
then
we
run
into
the
issue
that
this
table
does
not
yet
exist
so
before
we
can
actually
create
that
subscription.
Are
we
going
to
create
the
empty
tables
on
the
on
the
shard,
for
projects
and
for
users
cause?
So
let's
do
that
over
here.
So
we
have
this
reference
table
script,
basically
just
taking
a
schema
dump
from
projects
and
then
also
from
users
and
applying
that
to
the
shard
one
database.
A
It's
a
bunch
of
errors
because,
if
there's
references
to
other
tables
that
don't
exist
so,
but
that's
okay,
prefer,
if
or
not
so,
let's
retry
creating
the
subscription
and
that
worked
now.
We
can
basically
look
at
the
tables
in
the
public
schema.
We
should
see
projects
and
users
and
now,
after
creating
that
subscription,
those
are
being
populated
from
the
main
database
and
now
we're
basically
replicating
all
the
changes
from
the
main
database
into
you,
two
tables,
so
you
can
easily
select
from
those
tables.
You
see
the
same
content
as
in
theirs
and
laying
database
table.
A
Of
course
you
can
do
the
same
thing
on
the
second
chart,
but
that's
probably
not
terribly
interesting.
It's
the
same
kind
of
thing.
Now
what
this
means
is
we
can
actually
join
between.
We
can
go
to
a
chart
and
run
a
query
that
joins
between
one
of
the
reference
tables,
maybe
even
more
and
also
join
into
the
partitions
that
reside
on
the
shard.
A
A
Taking
this
one
step
forward,
what
would
be
interesting
is
to
not
have
to
deal
with
those
individual
partitions
here.
So
typically,
we
have
in
the
default
schema.
We
have
a
issues
table
right,
we
don't
care
about
partitions
and
none
of
they
create
explicitly
specify
a
partition.
I
have
sort
of
a
half-baked
approach
of
dealing
with
that
could,
for
example,
create
the
main
table
again.
So
this
is
the
since
the
one
that
we
have
by
default
and
let
that
look
like
one
of
the
practitioners
just
to
get
the
same
schema.
A
What
we
can
do
here
is
to
basically
attach
the
individual
tables
that
we
have
on
the
chart
and
attach
them
to
this
main
table.
This
is
basically
the
way
the
old
post
was
partitioning
work
like
we
use
table
inheritance
for
that,
so
we
can
say
all
the
table,
one
of
the
one
of
the
partitions
and
let
that
inherit
the
main
table
array
and
after
we've
done
that
and
we've
also
applied
it
with
the
other
partitions.
We
can
basically
work
with
the
original
main
table
and
we
basically
see
all
the
content
of
the
attached
partitions.
A
What
that
means
is
now
that
we
can
now
that
we
have
the
main
table
back
what
we
can
do
in
our
joint
queries.
We
don't
care
about
the
specifying
the
individual
partition
anymore,
but
we
can
just
use
the
standard
table
for
that
and
that's
still
going
to
work.
Obviously
that
only
hits
the
tables
or
the
partitions
that
are
attached
to
this
main
table
and
we
are
also
on
a
shard
so
on
a
on
the
shard
one
database,
and
that
means
we
don't
have
all
the
issues
available
so
only
like
Norwich's.
A
In
our
case,
we
only
have
half
of
the
partitions
available
on
trial
one.
So
looking
at
the
at
the
public
issues
table,
that's
only
going
to
give
us
like
half
of
the
of
the
actual
data
that
we
have
now.
This
could
be
useful
if
we
knew
that
some
data
exclusively
lives
on
chart1
and
or
the
data
we're
interested
in
exclusively
lives
on
that
chart.
So
what
we
could
do
is
if
we
had
a
project
ID,
maybe
that's
figure
out
which
one
this
is.
A
A
This
is
why
we
have
to
add
those
check
constraints
to
the
partition
such
that
we
can
statically
understand
which
partition
there.
We
have
to
look
at
now.
The
problem
with
that
is
those
partitions
they
basically
resemble,
or
their
data
resembles
what
we
created
earlier
in
the
main
database,
using
the
declarative
approach
and
what's
kind
of
interesting
with
that,
is
we
look
at
the
how
the
partitions
are
set
up?
A
Let's
see
that
we
have
eight
partitions
and
there
is
a
you
can
specify.
Morelos
and
reminder.
Remainder
problem
is
that
this
is
based
on
the
project
ID,
but
it's
actually
based
on
a
hash
of
the
protein
ID,
and
this
is
something
that
is
not
readily
available,
so
we
would
be
able
to
say
that
a
certain
partition
has
a
or
we
would
be
able
to
formulate
the
check
constraint
at
the
moment.
So
we
would
have
to
his
hash
function
to
make
that
work,
but
perhaps
that's
something
we
can
figure
out.