В CMDB есть ряд сущностей с разными свойствами. пробовал делать так - отдельная таблица со списком сущностей и свойства каждой в key-value в отдельной большой таблице. медленно, неудобно.

была как-то жеппа, связанная именно с таким сценарием, но что-то не могу припомнить что именно

Ну так https://t.me/sqlcom/149071 , т.е. в хоть сколько-нибудь нетривиальном случае наследование в PostgreSQL уже "не потянет" (там много существенных ограничений).

И у меня есть какие то фантомы в голове, но не могу найти где я это видел. Но спасибо, значит это не глюк

У нас есть несколько плоских таблиц которые получаются соединением нескольких файлов Excel на каждую дату, которые аналитики связывают сейчас по полям и тащут все это в локальный bi файл.
Вот теперь подобную структуру надо реализовать через хранилище. Если выгрузки можно сделать - ssis будет забирать их и кидать в хранилище, то дальше что с ними делать непонятно.

В итоге я пришел к тому, что есть кучка таблиц под каждый тип сущностей. Кроме идентификатора и имени в каждой таблице есть ряд их неотъемлемых свойств. А все, что меняется часто - в одной секционированной темпоральной таблице. Глобальный каталог - отдельная табилца, синхронизируемая на этапе вставки/удаления сущностей

+

Это не денормализовать, это композировать (восстановить после декомпозиции)

+

Вспомнил. Та проблема не связана работой RCSI. Там ghost cleanup на primary лочился в связи с висячим запросом на реплике.

Честно говоря, не могу представить механизма влияния на вторичку. Данные коммитятся как и раньше, передаются, применяются. ВРоде бы разницы нет

А есть где почитать?

Под рукой нет. это из полевой практики

Дай бог здоровья создателю канала✊🏻

However, row versioning also leads to another, less known phenomenon. Long running snapshot transactions on secondary nodes may defer ghost and version store cleanup on the primary node. Such transactions work with snapshots of the data as of the time when a given transaction began. Therefore, SQL Server cannot remove deleted rows and reuse their space because of the possibility that a snapshot transaction needs to access the old versions of the rows.

Не все так однозначно. Чтобы передавать 14 байт для версионности на вторичную реплику, первичка оставляет свободное место внутри лога для этих 14 байт. И я думаю, а не может ли это повлиять как-то. Ведь надо на первичке хранить 14 байт и ещё на вторичку пересылать пустоту для обеспечения rcsi там.

Благодарю

Гоп перелогинился? шучу 😊

А там не RSCI 😊 Там чистый SNAPSHOT. Читаем закоммиченные данные, так что пофиг ваще что там за изоляция на первичке. Я так думаю.