Comments 6
Спасибо за статью.
А можете прояснить - как работает DETACH | DELETE PARTITION? Как условный delete "из индекса" - т.е. для каждой строки в отсоединяемой партиции нужно будет найти и отметить строку в глобальном индексе? Или же записи остаются в индексе условно "живыми", а удалёнными отмечаются только при попытке доступа к ним?
>как работает DETACH | DELETE PARTITION?
При операциях удаления и DETACH PARTITION глобальный индекс не перестраивается. То есть, для глобального индекса является нормальным содержать некоторое количество недействительных данных (которые могут быть очищены с помощью команды VACUUM).
>Или же записи остаются в индексе условно "живыми", а удалёнными отмечаются только при попытке доступа к ним?
В глобальном индексе записи не помечаются как удалённые, так как в глобальном индексе хранятся не ссылки на версии записей в heap-таблицах (как в btree), а значения ключевых полей. Поэтому помечать как удалёнными записи не получится, так как при повторном добавлении записи с теми же значениями индексную запись придётся включать.
Спасибо за статью.
Есть вопрос: говоря о секционированных таблицах, вы имеете в виду таблицы, хранящиеся на одном сервере? То есть без использования шардирования в рамках распределенной базы данных?
Да, всё верно, имеются в виду таблицы, хранящиеся на одном сервере.
Для использования шардирования требуется, чтобы глобальный индекс также был распределён по разным серверам (вместе с соответствующими им данными в секциях).
Но текущая реализация глобального индекса изначально проектировалась без поддержки секционирования, поэтому нет и поддержки шардирования.
Глобальные индексы для секций в Postgres Pro: глобальная уникальность без костылей