►
From YouTube: 2021 05 11 TimescaleDB POC
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
All
right,
so
this
is
a
discussion
to
talk
about
a
time,
scale,
db,
proof
of
concept
or
demonstration.
So
with
that
wonderful
introduction
I'll
just
hand
it
over
to
nick,
and
we
can
start
talking
about
it.
So
nick
you
talked
about
during
database.
Scalability
working
group
it'd
be
quite
easy
to
put
together
a
time,
scale
db
proof
of
concept
because
we
had
not
actually
talked
about
using
that
for
the
time
decay
blueprint.
B
Right
so
for
time,
series
data,
it's
like
time,
scale
right
now
became
like
standard
de
facto
in
postgres
ecosystem
and
more
and
more
companies
are
using
it
and
it's
it's
been
developed
very
well,
so
so
they
implemented
various
interesting
things
related
to
compression
of
all
data.
B
They
also
released
recent,
like
they
have
a
lot
of
automation,
for
example,
automatic
deletion
of
old
old
chunks.
We
call
it
chunks,
but
it's
basically
partitions,
so
partitioning
management
fully
automated.
They
also
have
additional
functionality,
like
user
defined.
The
functions
like
metallized
views
used
to,
for
example,
we
can
use
it
to
track
some
counters
or
some
aggregates,
so
they
have
a
lot
of
functionality
and
it's
improving
I'm
I
was
very.
I
was
really
impressed
about
their
compression
work,
so
it's
like
very
interesting.
They
have
good
article.
B
I
can
send
you
so
like
skill
compression
you
just
can
google
it.
It
was
very
like
very
deep
and
impressive
material
and
it's
working.
It's
also
it's
open
source
they
made
last
last
year,
as
I
remember,
they
made
a
decision
to
make
everything
open
source
all
functionality
and
only
require
not
to
build
cloud
solutions
based
on
time
scale,
so
they
decided
at
all,
unlike
cytos,
which
distinguishes
open
source
and
enterprise
version
timescale
decided
to
have
all
functionality.
You
know
in
an
open
source
version
but
like
they
only
say,
don't
build.
B
As
I
understand,
maybe
I
like
I'm,
not
lower
and
so
on,
but,
as
I
understand
they
just
forbid
creation
of
cloud
offering
for
time
series
data
like
they
are
because
they
they
they
using
their
own
product.
What
else
we
like?
We
can
easily
check
some
tables.
I
I've
said
like
we
can
check
the
ci
builds
in
in
its
current
shape.
B
B
Split
table
to
chunks
so
partition,
basically
with
time
scale,
and
I'm
sending
this
like
very
quick
and
dirty
proof
of
concept
activity.
I
did
like
several
days
ago
here.
It's
it's
a
bad
form
and
snippet,
but
you
can
see
results
in
comments
there.
So
interesting,
interesting
observation.
I
had
let
me
point
you
to
some
additional
document.
B
I've
checked,
I
I
was
reading
different
materials
about
what
to
do
with
plans,
what
to
do
with
sea
bills,
and
I
was
curious
how
current
workload
or
ci
bills
would
looks
like
and
also
create
this
document
also
sending
to
our
to
our
zoom
chat.
So
let
me
share
my
screen
also,
and
we
will
discuss
it.
B
So
this
is
basically
some
dump
of
progesterone
statements
for
ci
builds
order
by
calls
in
reverse
order,
and
we
see
these
queries
and
I
was
manually
checking.
We
can
automate
it
of
course
and
understand
patterns
here,
but
basically
some
queries.
We
have
single
lookup
from
primary.
I
think
I'm
sure
other
people
already
also
did
similar
analysis,
but
just
to
be
on
the
same
page.
B
So
we
have
some
queries,
which
are
basically
primary
key
lookup
based
on
id
and
many
many
queries
are
searched
by
commit
id
which
commit
ideas,
understand,
don't
commit
id,
it's
a
pipeline
id
right,
so
id
of
because
I
see
foreign
key
to
pipeline
stable,
so
this
commit
id
is
something
special,
as
I
understand
for
when
we
work
with
serbians.
So
that's
why
I
decided
in
my
experience
I
I
considered
commit
id
as
time
because
I
don't
see
created
ad
at
all
here
right,
so
we
cannot
choose
create
that
as
our
time.
B
If
we
want
to
partition
by
times
recycles,
I
I
did
very
like
a
very
independent
experiment,
so
just
consider
it
as
again
some
dirty
data,
the
dirty
proof
of
concept,
so
I
use
commit
ideas
as
our
time,
because
it's
incrementally
growing
in
time
and
oh,
like
lower,
commit
id
means
some
old
data.
Newer
means,
like
some
newer
data,
so
it's
some
integer,
of
course,
right
of
course,
time
scale
can
work
with
both
lift
time
time
stamps
and
integers
people
do
it,
and-
and
it's
it's
it's
okay.
Moreover,.
B
Right
this
is
interesting.
This
is
interesting.
If
we
choose
time,
for
example,
we
say
we
want
months,
then
some
old
months
will
will
have.
We
will
have
much
less
data
than
new
months
right,
because
rates
are
increasing.
If
we
choose
commit
id.
I
took,
I
believe,
one
million
as
chunk
size
chunk
time
interval.
It's
called
time,
but
it's
like
because
originally
they
created
it
for
time,
but
integers
also
supported.
So
we
need
to
ignore
this
word
here
and
I
took
1
million,
but
I
worked
only
with
partial
data.
B
You
see
it
here
I
filled
only
with.
I
believe
it.
It's
only
two
last
months
like
march
and
april,
because
it
also
raised
a
lot
of
you.
You
can
see
a
lot
of
data
here
so
after
I
did
it.
I
checked
some
queries
very
briefly,
and
I
saw
of
course,
if,
if,
if
query,
if
query
includes,
if
query
includes
our.
A
B
I
don't
have
it
here,
yeah
I'll
put
it
here
or
or
when,
where
you
want
to
discuss
it,
I
can
put
it
there
as
well.
So
I
mean,
if
query
has
filter
on
commit
id.
It's
very
fast
super
fast.
Of
course,
planning
time
is
increased,
but
I
believe
the
same
problem
we
observed
when
we
implemented
the
custom
partitioning
when
we
have
a
lot
of
partitions
first
time.
We
call
a
query.
B
It
has
very
big
planning
time.
So
this
is
a
separate
problem.
We
need
to
discuss
it.
There
are
some
approaches
to
it,
but
it's
like
it's
independent
on
the
tool
we
we
use
like
our
own
solution
for
partitioning
or
timescale,
but
the
second
column
and
others
were
very
well
like
I
compared
like
querying
original
table
and
partition
table
with
timescale.
It
worked.
It
worked
well
an
interesting
thing.
Additionally,
we
can
use
two
dimensions
for
partition.
B
It's
like
it's
like
some
thought
towards
sharding,
because
time
scale,
two,
they
also
have
shading
and
we
can
use
not
only
time
climate
id
in
our
case,
but
also
project
id
ci
bills
doesn't
have
name
space
so
for
dirty
proof
of
concept.
I
used
project
id
and
I
said
we
want
to
split
it
by
three
three
like
big
chunks
or
how
three
parts
by
project
id
and
then
shrink
two
chunks,
one
billion
each.
B
So
it's
like
two-dimensional
partitioning
and
additionally,
I
checked
experiment.
I
checked
experiments
with
for
sharding.
It
was
a
little
bit
more
difficult,
so
I
had
three
shards
based
on
project
id
inside
each.
We
had
partitions
of
one
million
by
by
commit
id,
but
it's
it's
already
beyond
this
discussion,
so
I'm
not
going
to
advocate
time
scale
for
sharding.
It's
it's
quite
more,
it's
more
difficult
topic,
but
for
partitioning
I
see
it's,
we
could
benefit
from
it.
B
If
at
least
we
need
to
explore
it
because
what
they
do
like
it's,
it
looks
interesting
and
like
features
they
have
either
we
need
to
use
them
or
we
need
to
implement
same
features
ourselves.
B
C
C
A
C
A
C
Seed
that
you
shared
with
us
is
very
interesting
because
it
shows
you
know
the
workload
over
sky
beats.
So
this
is
something
that
we
should
do
either
way,
but
other
than
that.
How
is
time
bb
going
to
help
us
on
top
of
using
pure
posters
now,
but
we
have
the
tools.
B
B
B
So
it's
like
some
additional
helper
mechanism
that
help
you
helps
you
have
aggregates
pre
pre-calculated.
Then
they
have
user-defined
actions.
So
it's
like
a
background
jobs
on
chunks,
not
sure
it's
needed,
because
we
have
our
own
background
system,
then
automatically
ordering
data
in
chunks
physically
by
indexes
kind
of
cluster
for
postgres,
but
but
for
chunks
only
so
they
have
these
features
to
work
with
very
large
volumes
of
data.
B
C
C
If
you
have
most
of
your
queries
are
in
what
we
we
would
call
the
latest
partition,
because
they
are
doing
a
lot
of
work
to
keep
the
latest
partition
in
memory.
C
So
if
we
don't
have
that
case,
so,
for
example,
we
just
partitioned
webco
clocks
by
date
and
in
the
case
of
webhook
logs,
we
always
query
the
last
seven
days.
In
that
case,
I
assume
that
the
time
scale
db
will
be
perfect,
but
for
all
other
cases,
if
we
want
to
do
you
know
normal
partition,
let's
say
10
and
partitioning
or
whatever,
where
you
don't
always
access
the
same.
The
last
one
and
good
times
kdb
be
useful
for
those
cases,
or
it
will
be
only
for
for
the
case
where
we
have.
C
You
know
the
the
time
data,
the
time
constraint,
data.
B
Well,
it's
a
good
question.
Actually,
if
we
first
of
all
about
cash,
I
don't
think
the
only
case
when
time
scale
or
any
time
based
partitioning
works.
Well,
is
when
you
access
the
only
fresh
data.
Postgres
caches
pages,
not
whole
table
right,
so
we
can
cache
some
old
partitions
partially
and
still
benefit
from
it.
It's
kind
of
it
it
it's
make.
It
makes
better
maintenance
tasks
like
index
recreation.
B
Why
auto?
Because
we
can
paralyze
it
and
utilize
more
course
to
process
one
single
big
entity
and
but
with
respect
to
cash.
I
like
it's
like
it's
page
level,
so
I
don't
think
I
don't
think
you
like.
You,
cannot
query
old
data
but
of
course,
like
with
time
scale
and
any
like
time,
series
approach.
B
It's
I
I
would
say
it's
not
it's
not
about
selects
it's
about,
updates
but
and
maybe
delete.
So
it's
it's
not
like
it's
working
less
and
less.
Well,
if
you,
if
you
update
all
data
a
lot
or
delete
all
data
to
not
not
just
print
partition
like
dropping
it
completely,
but
you
need
to
delete
some
partitional
records.
Did
you.
B
Right
right
because
it's
like
updating
rows,
especially
if
you,
for
example,
you
need
to
update
some
old
row
and
your
update
is
moving
into
different
positions.
This
is
the
worst
case,
okay,
so
but
the
same
thing
for
time-based
partitioning
and
postmas
for
not
time-based
partitioning.
It's
like,
like
time-scale,
guys
open
their
talks.
I
I
saw
it
like
they
say
all
data
in
the
world
is
times
that
time
serious
data.
B
This
is
like
interesting,
saying:
I'm
not
100,
like
percent
convinced,
but
it's
interesting
to
think
about
it
in
this
case.
So,
but
if
you
think
about
gitlab
that
the
most
of
data
is
is
has,
of
course,
not
everything,
but
but
especially
big
tables,
where
we
have
a
lot
of
data,
it's
it's
produced
over
time,
so
we
can
think
about
the
time
series.
C
Yeah,
but
that's
not
the
case
if
we
start
if
we
want
to
chart
or
partition
by
namespace,
for
example,
or
do.
B
B
C
A
C
B
Well,
yes,
like
two
things
here:
first,
if
we,
if
we
think
about
using,
for
example,
project
id
as
time
like
to
as
a
single
dimension
to
partition
and
think
about
it
as
time,
it
will
be
not
a
good
idea.
I
think,
because
we
cannot
there's
not.
There
is
no
very
old
tail
that
we
could
compress
or
even
delete.
B
A
B
B
B
I
agree
with
you
right
and
but
it's
it's
about
all
time,
serious
positioning,
I
I
I
know
some
people
try
like
to
think
about
like
let's
take
time
scale,
because
we
want
to
do
to
deal
with
partitioning
because
it
still
needs
a
lot
of
things
to
implement
like
pruning
and
and
management
of
partitions
right.
So
let's
take
it
and
use
it.
It's
not
not
a
good
direction
to
to
use
it,
but
they
also
have
second
ability
to
create
second
dimension
for
partitions.
B
So
if
it's,
if
it's
not
time
serious
time,
decay
data
at
all,
not
probably
not
a
good
idea,
that's
why
I'm
not
pushing
this
as
a
tool
for
sharding
right.
I
probably
will
raise
it
a
little
bit
later
if
we
start
thinking
about
sharding
parts
of
database,
so
vertical
sharding
circle
right.
So
if
if
we
go
this
direction,
we
can
take
part
of
database
which
truly
has
times
time
serial
time
series
nature
like
ci
data.
In
this
case,
maybe
it
will
be
interesting
to
consider
time
series
or
at
that
time
scale.
B
C
A
B
I
my
answer
is,
I
think,
no
restrictions,
but
I
will
check
with
I
don't
know
who
are
experts
in
in
licenses.
B
B
You
create
extension.
This
is
what
I
did
I
this
my
snippet
like
I
sent
to
our
chat
it.
Actually
it
should
have
if
it
doesn't.
I
I
will
like.
Let
me
let
me
know
where
we
discuss
it
issue
or
something
I
will
put
instructions,
how
quickly
try
it
it's
quite
easy,
so
we
create
extension,
adjust
the
sharepoint
libraries
restart
needed,
of
course,
because
it's
extension,
which
requires
restart
and
that's
it.
So
we
can
create
a
so-called
hyper
table.
They
call
it
hyper
table,
so
it's
distributed
table
and
start
moving
data.
B
There
interesting
question
how
to
migrate
online,
but
it's
it's
so
they
don't
provide
the
tools
for
migrate
online
migration
of
fortunately,
so
you
need
to
develop
it.
That's
it
so
like.
C
So
why-
and
I
agree
why
build
the
additional
yeah
tooling,
but
we
have
to
understand
how?
What
are
the
problems
with
enabling
it
and.
C
Is
this,
so
this
is
a
plugin
that
needs
building
or
or
is
it
supported
by
the
so.
B
I
think
so
we
just
installed
this
extension,
so
it's
easy
and
what
I
wanted
to
say
they
also.
It
has
interesting
time
scale
scheme
like
information
schema.
You
know
this,
like
sql
standard
api,
to
understand,
like
some
meta
information
about
about
database
like
to
see
which
columns,
table
tables
have
and
so
on,
so
they
created
their
own
like
additional
schema
to
expose
some
stats
and
so
on
about
what
is
happening
with
data.
A
Okay,
so
I
gotta
drop
off
here
and
then
I
got
another
meeting
to
run
too
so
I'll
create
an
issue
where
we
can
discuss
this.
It
doesn't
sound
like
it's
blocking
our
implementation
of
anything
right
now,
but
it's
something
we
should
discuss
for
accelerating
any
kind
of
time,
decay
that
we
may
want
to
do
in
the
future.