Não há necessidade de criar uma restrição única na dimensão do tempo. Isso funciona:
CREATE TABLE event (
id serial,
ts timestamp with time zone NOT NULL,
details varchar(255) NOT NULL
);
SELECT create_hypertable('event', 'ts');
Observe que a chave primária em
id é removido. TimescaleDB requer que qualquer restrição exclusiva ou chave primária inclua a dimensão de tempo. Isso é semelhante à limitação do PostgreSQL no particionamento declarativo para incluir a chave de partição na restrição exclusiva:
O TimescaleDB também impõe exclusividade em cada bloco individualmente. Manter a exclusividade entre os fragmentos pode afetar drasticamente o desempenho de ingestão.
A abordagem mais comum para corrigir o problema com a chave primária é criar uma chave composta e incluir a dimensão de tempo conforme proposto na pergunta. Se o índice na dimensão de tempo não for necessário (nenhuma consulta somente no tempo é esperada), então o índice na dimensão de tempo pode ser evitado:
CREATE TABLE event_hyper (
id serial,
ts timestamp with time zone NOT NULL,
details varchar(255) NOT NULL,
PRIMARY KEY (id, ts)
);
SELECT create_hypertable('event_hyper', 'ts', create_default_indexes => FALSE);
Também é possível usar uma coluna inteira como a dimensão de tempo. É importante que essa coluna tenha propriedades de dimensão de tempo:o valor está aumentando ao longo do tempo, o que é importante para o desempenho da inserção, e as consultas selecionarão um intervalo de tempo, que é crítico para o desempenho da consulta em um banco de dados grande. O caso comum é para armazenar unix epoch.
Desde
id em event_hyper é SERIAL, aumentará com o tempo. No entanto, duvido que as consultas selecionem o intervalo nele. Para completar o SQL será:CREATE TABLE event_hyper (
id serial PRIMARY KEY,
ts timestamp with time zone NOT NULL,
details varchar(255) NOT NULL
);
SELECT create_hypertable('event_hyper', 'id', chunk_time_interval => 1000000);
