create_hypertable. Since 1.0.0
Creates a from a table (replacing the latter),
partitioned on time and with the option to partition on one or more other
columns. The table cannot be an already partitioned table
(declarative partitioning or inheritance). In case of a non-empty table, it is
possible to migrate the data during creation using the migrate_data
option, although this might take a long time and has certain limitations when
the table contains foreign key constraints (see below).
After creation, all actions, such as ALTER TABLE, SELECT, etc., still work
on the resulting .
For more information about using s, including chunk size partitioning,
see the hypertable documentation.
Samples
Convert tableconditions to with just time partitioning on column time:
conditions to , setting chunk_time_interval to 24 hours.
conditions to . Do not raise a warning
if conditions is already a :
measurements on a composite column type report using a
time partitioning function. Requires an immutable function that can convert the
column value into a supported column value:
events, on a column type jsonb (event), which has
a top level key (started) containing an ISO 8601 formatted timestamp:
Arguments
The syntax is:Returns
If you use
SELECT * FROM create_hypertable(...) you get the return value
formatted as a table with column headings.
The use of the
migrate_data argument to convert a non-empty table can
lock the table for a significant amount of time, depending on how much data is
in the table. It can also run into deadlock if foreign key constraints exist to
other tables.
When converting a normal SQL table to a , pay attention to how you handle
constraints. A can contain foreign keys to normal SQL table columns,
but the reverse is not allowed. UNIQUE and PRIMARY constraints must include the
partitioning key.
The deadlock is likely to happen when concurrent transactions simultaneously try
to insert data into tables that are referenced in the foreign key constraints
and into the converting table itself. The deadlock can be prevented by manually
obtaining SHARE ROW EXCLUSIVE lock on the referenced tables before calling
create_hypertable in the same transaction, see
documentation
for the syntax.
Units
Thetime column supports the following data types:
The type flexibility of the ‘time’ column allows the use of non-time-based
values as the primary chunk partitioning column, as long as those values can
increment.
jsonb) you can specify a function to
the time_partitioning_func argument which can extract a compatible data type.
The units of chunk_time_interval should be set as follows:
- For time columns having timestamp or DATE types, the
chunk_time_intervalshould be specified either as anintervaltype or an integral value in microseconds. - For integer types, the
chunk_time_intervalmust be set explicitly, as the database does not otherwise understand the semantics of what each integer value represents (a second, millisecond, nanosecond, etc.). So if your time column is the number of milliseconds since the UNIX epoch, and you wish to have each chunk cover 1 day, you should specifychunk_time_interval => 86400000.
number_partitions is greater
than zero), it is possible to optionally specify a custom partitioning function.
If no custom partitioning function is specified, the default partitioning
function is used. The default partitioning function calls ‘s internal
hash function for the given type, if one exists. Thus, a custom partitioning
function can be used for value types that do not have a native hash
function. A partitioning function should take a single anyelement type
argument and return a positive integer hash value. Note that this hash value
is not a partition ID, but rather the inserted value’s position in the
dimension’s key space, which is then divided across the partitions.
The time column in
create_hypertable must be defined as NOT NULL. If this is
not already specified on table creation, create_hypertable automatically adds
this constraint on the table when it is executed.