Atualmente, tenho uma tabela relativamente grande contendo dados de séries temporais (mais de 628 mil linhas ao vivo). A definição da tabela (alguns nomes mudaram ligeiramente) na parte inferior da pergunta.
Desejo anexar a tabela existente como uma partição a uma nova tabela (particionada). No entanto, a tabela existente possui uma id
chave primária singular (usada principalmente porque o Django a exige). Anexar a tabela exigiria que eu atualizasse a restrição de chave primária (id, timestamp)
na tabela antiga.
Como id
é exclusivo, isso não é um problema, mas, dado o tamanho da tabela, me pergunto se essa restrição é verificada na criação (levando a uma consulta bastante) ou se apenas as linhas recém-adicionadas/atualizadas são verificadas. É possível interromper a leitura/gravação na tabela por alguns minutos, mas não posso esperar várias horas.
Nova mesa pretendida
Como a tabela antiga, a id
coluna é exigida principalmente pelo nosso ORM, infelizmente. Um (prop_id, "timestamp", value)
índice semelhante também seria usado na tabela particionada.
CREATE TABLE "newtable" (
"id" bigserial NOT NULL,
"timestamp" timestamp with time zone NOT NULL,
"prop_id" integer NOT NULL,
"value" double precision NOT NULL,
PRIMARY KEY ("id", "timestamp")
) PARTITION BY RANGE ("timestamp")
;
Definição de tabela antiga
A "id"
chave primária é um artefato do nosso ORM (Django) e é irrelevante para qualquer consulta que fazemos. Usamos o (prop_id, "timestamp", value)
índice 99,9% do tempo para varreduras somente de índice.
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
-----------+--------------------------+-----------+----------+----------------------------------------------------------+---------+--------------+-------------
id | bigint | | not null | nextval('tablename_id_seq'::regclass) | plain | |
timestamp | timestamp with time zone | | not null | | plain | |
value | double precision | | not null | | plain | |
prop_id | integer | | not null | | plain | |
Indexes:
"tablename_pkey" PRIMARY KEY, btree (id)
"tablename_prop_id_timestamp_value_b9bc8326_idx" btree (prop_id, "timestamp", value)
Foreign-key constraints:
"tablename_prop_id_67f339b0_fk_othertable" FOREIGN KEY (prop_id) REFERENCES othertable(id) DEFERRABLE INITIALLY DEFERRED
Proceda assim:
Não crie uma restrição de chave primária na tabela particionada por enquanto. Em vez disso, crie índices exclusivos nas novas partições que mais tarde se tornarão partições do índice de chave primária.
Assim que a tabela grande tiver idade suficiente para que você não precise mais dos dados, descarte-a.
Em seguida, você pode criar uma chave primária na tabela particionada que usará os índices exclusivos já existentes como partições.