Non è necessario creare un vincolo unico sulla dimensione temporale. Funziona:
CREATE TABLE event (
id serial,
ts timestamp with time zone NOT NULL,
details varchar(255) NOT NULL
);
SELECT create_hypertable('event', 'ts');
Nota che la chiave primaria su id
viene rimosso.
TimescaleDB richiede che qualsiasi vincolo univoco o chiave primaria includa la dimensione temporale. Questo è simile alla limitazione di PostgreSQL nel partizionamento dichiarativo per includere la chiave di partizione nel vincolo univoco:
TimescaleDB impone anche l'unicità in ogni blocco individualmente. Il mantenimento dell'unicità tra i blocchi può influire notevolmente sulle prestazioni di importazione.
L'approccio più comune per risolvere il problema con la chiave primaria è creare una chiave composita e includere la dimensione temporale come proposto nella domanda. Se l'indice sulla dimensione temporale non è necessario (non sono previste query solo sulla dimensione temporale), è possibile evitare l'indice sulla dimensione temporale:
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);
È anche possibile utilizzare una colonna intera come dimensione temporale. È importante che tale colonna disponga di proprietà della dimensione temporale:il valore aumenta nel tempo, che è importante per le prestazioni di inserimento, e le query selezioneranno un intervallo di tempo, che è fondamentale per le prestazioni delle query su database di grandi dimensioni. Il caso comune è per la memorizzazione di unix epoch.
Da id
in event_hyper
è SERIAL, aumenterà con il tempo. Tuttavia, dubito che le query selezioneranno l'intervallo su di esso. Per completezza SQL sarà:
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);