Как партиционировать большую таблицу в PG 11?

Question

[Владимир]

Есть очень большая таблица на 5TB, сейчас это один кусок данных
(сама таблица оч простая:)

Table "public.history"
Column | Type | Collation | Nullable | Default
--------+---------------+-----------+----------+---------
itemid | bigint | | not null |
clock | integer | | not null | 0
value | numeric(16,4) | | not null | 0.0000
ns | integer | | not null | 0
Indexes:
"history_1" btree (itemid, clock)

Как можно её партиционировать не вызывая долгие простои в бэкенде на запись в эту таблицу? чтобы в будущем я мог дропнуть одну партицию в 5tb а не удалять записи данных по частям целыми днями.

Comments

[Евгений]

Заббикс что ли? :)

Рекомендую покурить timescale:
https://www.zabbix.com/documentation/current/en/ma...

[rPman]

без информации о характере использования этой таблицы ответить невозможно. У тебя записи идут строго с повышением времени? т.е. добавляются но не модифицируются? по какому критерию ты собираешься делить данные? само собой можно догадаться что если есть clock то можно делить по нему но повторяю, только если старые данные никто не трогает...

[Владимир]

Евгений, Он самый, изучу сяп.

[Владимир]

rPman, Да всё так растущий объём, своего рода времяной ряд по clock. в ответах уже подсказали правильный ответ, спасибо.

Answer 1

[Melkij]

если clock это unixtime, а так же именно по нему и хотим партиционировать в дальнейшем:

begin;
set local statement_timeout to '100ms';
alter table history add constraint partition_key check (clock < :N) not valid;
commit;
alter table history validate constraint partition_key;
begin;
set local statement_timeout to '100ms';
alter table history rename to history_old_data;
create table history (...) partition by range (clock);
alter table history attach partition history_old_data for values from (minvalue) to (:N);
create table history_part_... partition of history for values from (:N) to (...);
commit;

:N - некая дата в будущем, до неё данные будут писаться в старую 5тб табличку, после - в новую партицию. Если до выбранного :N не успеете завершить миграцию - то удалить check constraint, иначе запись, конечно, встанет.

Comments

[Владимир]

Почему-то был уверен что not valid; нет в 11 версии. Спасибо

[Melkij]

это старая штука, ещё в 9.1 появился not valid для foreign key и в 9.2 для check'ов