что можно
Но как же в таком случае соблюдать это ограничение?
Уникальное ограничение — это уникальный индекс. Уникальные индексы у каждой партиции физически отдельные. Если создать уникальный индекс по полю, не связанному с партицированием то получится, что уникальность проверяется только в рамках одной партиции. Поэтому возможны только такие уникальные индексы, у которых поля партицирования являются префиксом (как и вообще все индексы должны начинаться с полей партицирования)
Последнее-то вы с чего взяли?
если у меня поле партиционирования это id (pk) - то уникальности никакой не будет если я его добавлю в ограничение
Да никак, это известное ограничение партицый постгрес.
Хорошая новость: чаще всего вам это не очень и нужно. Если вы в первый раз с этим столкнулись — то 100% не нужно.
Мне надо подумать... Наверное, если индекс не партицированный, а консолидированный, то невозможно отцепить партицию. Поэтому он должен быть тоже партицированный
В постгресе нет консолидированных индэксов (и это не имеет отношэния к вопросу).
ну как же не нужно - нам не нужны в таблице конфликты!
Вам, скорее всего, и партицыонирование-то не нужно.
секционирование нужно - потому что документов (мусора) будет уйма и они спустя время совсем не нужны будут
Во всяком случае, придумать use-case, в котором есть числовой id и нужны партицыи — довольно сложно.
Во-первых, в таком случае партицыонируют по дате или по полю "в архив". Ну, включая это поле (часть поля) в pk, да. Во-вторых, чаще всего выигрыш от truncate или detach partition — не стоит вообще усилий. Во-третьих, какая вам разница — ну, будут дубликаты появляться до детача архивов, а не после. Факта дубликатов это не отменяет.
но мне же не нужно всю таблицу документов очищать - нужно удалять будет старые документы (в ручную в архив их никто переводить не будет)
Ещё раз: смысл какой-то в этом появляется для нормальной нагрузки когда размеры таблицы переваливают за несколько тэрабайт. Лучшэ в районе 10. А так -- DELETE замечательно работает, особенно на SSD.
по дате можно, но у нас 2 но: - по дате размер полей секционирования будет больше на 64 байта - предполагалось что клиенты генерируют Id на своей стороне
ну понятно что DELETE на большой таблице потребует и время и ресурсы
То, чем вы занимаетесь называется "преждевременная оптимизацыя". Она с вероятностью 1 приведёт к тому жэ, к чему обычно -- вы заплатите приличным дополнительным геморроем за то, что у вас всё будет работать несколько медленнее.
почему? мы планируем держать актуальными пару секций (секция-месяц) - нагрузка я думаю будет гораздо ниже чем на сплошную таблицу
И да, дело тут, конечно, в том, что в Postgres плохое партицыонирование. Было бы хорошэе -- можно было бы лепить его куда ни попадя по принцыпу "хужэ не будет". Но партицыонирование тут уж какое есть.
Обсуждают сегодня