A maneira padrão do postgresql também é possível em uma hipertabela com escala de tempo?
CLUSTER [VERBOSE] tablename [ USING indexname ]
Exemplo:
- Criando tabela e hypertyble
CREATE TABLE IF NOT EXISTS l1(
timestamp TIMESTAMP(6) NOT NULL,
data VARCHAR(8) NOT NULL,
SELECT create_hypertable('l1', 'timestamp', chunk_time_interval => interval '1 day');
- Produz um índice como este ( pode ser visualizado usando este comando ):
l1 | l1_timestamp_idx | CREATE INDEX l1_timestamp_idx ON public.l1 USING btree ("timestamp" DESC)
- E do que
CLUSTER
os dados como este
CLUSTER l1 USING l1_timestamp_idx;
stdout: CLUSTER
Parece que funciona. Mas isso é recomendado? E é possível inverter a ordem do CLUSTER
comando? Ou seja, classificá-lo com o menor timestamp primeiro.
Recomendamos usar o comando reorder_chunk do TimescaleDB (ou uma política de reordenação).
O CLUSTER terá um bloqueio ACCESS EXCLUSIVE em toda a hipertabela, o que impede que quaisquer operações (leituras ou gravações) ocorram durante todo o processo do cluster ( https://www.postgresql.org/docs/current/sql-cluster.html ).
Nós reimplementamos uma funcionalidade semelhante
reorder_chunk
para não exigir um bloqueio tão pesado: ele opera pedaço por pedaço, e você ainda pode ler a partir da tabela/pedaço enquanto a reordenação/agrupamento está ocorrendo.Mas respondendo suas outras perguntas:
Você pode fazer o pedido em qualquer ordem de carimbo de data/hora. Defina seu índice a ser agrupado/reordenado como tendo registros de data e hora DESC (descendente) ou ASC (crescente).
Reordenar pedaços pode ser realmente ótimo para o desempenho. Normalmente, você não precisa apenas de carimbo de data/hora se estiver inserindo dados em uma ordem de carimbo de data/hora solta. Mas geralmente os vemos em composições, portanto, se você tiver um dispositivo e carimbo de data/hora, e muitas vezes fizer uma consulta como:
então é muito útil reordenar com base em um índice composto como (device_id, timestamp).
https://docs.timescale.com/latest/api#reorder_chunk https://docs.timescale.com/latest/api#add_reorder_policy