Вроде бы да (насколько я вижу). Но это не самый лучший метод в плане именно длительности блокировок... с другой стороны, альтернатива (с разбиением на отдельные шаги) сложнее (и возможно, вовсе не нужна на Ваших объёмах).
а какие еще варианты? эти записи меняться не будут никогда, архивное. Сделать полные копии и очистить от лишнего?
О, ну накрутить-то тут можно, в таком случае (если данные в этом диапазоне статичны): 1. Сначала создать logs_2023_08_28 без индексов. 2. Потом в неё залить данные. 3. Потом создать "любимый" индекс (который будет нужен большинству запросов). 4. Выполнить по нему CLUSTER. 5. Создать остальные индексы + все полезные CHECK (особенно тот, что точно соответствует диапазону partitioning). 6. Выполнить VACUUM ANALYZE; 7. И далее уже в транзакции: DELETE FROM logs_default where ...; ALTER TABLE logs ATTACH PARTITION logs_2023_08_28 ... Но, опять-таки, зачем?. ;)
блин.. в доке исправлю. протестить уже не на чем
Неужели у Вас тестовой базы нет? ;) В любом случае, суть тут в том, что таким Вы выносите проверку этой constraint из транзакции. Этот CHECK, кстати, можно удалить после ATTACH — он свою роль уже выполнил и больше не понадобится.
а я удаляю же ALTER TABLE user_action_log_2023_08_27 DROP CONSTRAINT user_action_log_2023_08_27;
Ну да, я имел в виду, что это правильно.
Обсуждают сегодня