This change refactors the chunk index handling to make better use
of standard PostgreSQL catalog information, while removing the
hypertable_index metadata table and associated triggers, including
those on the chunk_index table. The chunk_index table itself is
also simplified.
A benefit of this refactoring is that indexes are no longer
created using string mangling to construct the CREATE INDEX command
for a chunk, based on the string definition of the hypertable
index. Instead, indexes are created in C using proper index-related
internal data structures.
Chunk indexes can now also be renamed and are added in the parent
index tablespace. Changing tablespace on a hypertable index also
recurses to chunks, as expected. Default indexes that are added when
creating a hypertable use the hypertable's tablespace.
Creating Hypertable indexes with the CONCURRENTLY modifier is
currently blocked, due to unclear semantics regarding concurrent
creation over many tables, including how to deal with snapshots.
Streamline code and remove triggers from chunk and
chunk_constraint. Lots of additional cleanup. Also removes need to CASCADE
hypertable drops (fixes#88).
This PR add support for primary-key, foreign-key, unique, and exclusion constraints.
Previously supported are CHECK and NOT NULL constraints. Now, foreign key
constraints where a hypertable references a plain table is support
(while vice versa, with a plain table references a hypertable, is still not).
Previously dimension_slice would only allow ranges to start and
end with values >= 0. However, this did not allow for timestamps
prior to 1970 because those times would be represented by negative
integers. With this PR we now support dates prior to 1970.
Addresses issue #153.
SQL code is now split into setup, functions, and init files to
allow a subset to be run when the extension is updated. During
build, an update script is now also generated.
A new public-facing API `add_dimension(table, column, ...)`
makes it possible to add additional dimensions (partitioning
columns) to a hypertable.
Currently, new dimension can only be added to empty tables.
The code has also been refactored with a corresponding
internal function that is called by both `add_dimension()`
and `create_hypertable()`.
Tablespaces can now be associated with a hypertable
using the new user-facing API attach_tablespace().
Alternatively, if the main table, which is to be
converted into a hypertable, was created with an
associated tablespace, that tablespace will
automatically be associated also with the hypertable.
Whenever a chunk is created, a tablespace will be
chosen from the ones associated with the chunk's
hypertable (if any). This is done in a way that ensures
consistency in one dimension. I.e., if a hypertable
has a closed (space) dimension with a fixed number
of slices (ranges), it will ensure that chunks that
fall in the same slice will alsp be stored in the same
tablespace.
If a hypertable has more than one closed dimension,
the first one will be used to assign tablespaces
to chunks. If the table has no closed dimensions, but
one or more open (time) dimensions, then the first
time dimension will be used. However, since open
dimensions do not have a fixed number of slices,
tablespaces will be assigned in a round-robbin
fashion as new slices are created. Still, chunks
in the same time slice will be stored in the same
tablespace.
Also in this commit:
- Rename time/space to open/closed for more generality.
- Create a Point data type for mapping a tuple to an
N-dimensional space.
- Numerous fixes and cleanups.
This is the first stab at updating the table and data type
definitions in the catalog module in the C code. This also
adds functions for natively scanning the dimension and
dimension_slice tables.
The current schema and code support only one "time" and one "space"
dimension for partitioning. While this is probably good enough for
many applications, it won't allow partitioning along two "space"
dimensions, like longitude and latitude, for instance.
This commit is a first stab at refactoring the metadata schema and
internal functionality to support any number of partitioning
dimensions. The idea is to think of a hypertable as partitioned in N
dimensions, where a partition (chunk) is a hypercube in the
N-dimensional hyperspace. Each dimension is divided into a number of
"slices" (dimensional partitions) that each occupies a range along the
dimension's keyspace axis.
A dimension can either be "closed" or "open", indicating a space-like
or time-like dimension, respectively. Closed dimensions have a limited
number of partitions that cover the entire domain. Open dimensions have
an unlimited number of partitions and thus must be created on-demand
as needed for the inserted data.
Note that the open/closed notation is preferred over time/space, since
an open dimension could be used for something other than time (for
instance, a sequence number). Conversely, closed dimensions need not be
space-like as it is entirely possible to use time as a closed
dimension.
Another advantage of this refactoring is that it now unifies a lot
of the logic for time and space that used to be separate.
On a schema-level, this gets rid of partition/partitition_epoch tables and
replace them with dimension, dimension_slice, and chunk_constraint. It
also removes the time columns associated with a chunk and instead makes
this a separate dimension stored as a chunk_constraint.
Clean up the table schema to get rid of legacy tables and functionality
that makes it more difficult to provide an upgrade path.
Notable changes:
* Get rid of legacy tables and code
* Simplify directory structure for SQL code
* Simplify table hierarchy: remove root table and make chunk tables
* inherit directly from main table
* Change chunk table suffix from _data to _chunk
* Simplify schema usage: _timescaledb_internal for internal functions.
* _timescaledb_catalog for metadata tables.
* Remove postgres_fdw dependency
* Improve code comments in sql code
