*перекрестился*))

у меня два года prod крутится - основной вопрос - задача. по гибкости и удобству выше всех похвал, по быстродействию нет нареканий SSD + задача без высоких требований.   На мой взгляд, для задач dev   идеально

ну раз уж начали в чем гибкость в чем удобство применительно к пг?

intarray это не стандартный тип получается?

неужели нельзя jsonb (внутри числовые массивы) сравнить каким то образом на пересечение

функция || объединяет два jsonb поля
а есть ли ф-я пересечения?

- обновление minor / major, мониторинг, квоты,  развертывания для проведения тестов восстановления  + самое главное = прозрачность действий ПОДРЯДЧИКОВ !!! никаких больше rm -rf / это оно само при компиляции pg

а трудно спросить официальную доку, и вообще про массивы почитать?

в 12 легко и даже гораздо сложнее.

вы когда в json запихивали массивы думали как доставать будете?

вообщем integer[] тип нужно было юзать

А есть какая-то конкретика? Чем чревато, что ждать.

в довесок удобство организации backup - у меня wal-g + s3 + ssd prod / ssd backup  + mellanox  - развертывание с 0 (новый узел docker) - до состояние instance  отдает данные - ~<= 5 минут - Instance  5-10 гб.

ясно. спасибо.

у меня нет, только плеванием участников чата, вопросами про затёртые данные, и парой неплохих докладов с пгконф (не помню чьи, просто смотрел)

А насколько актуальны эти данные? Я тоже слышал только негатив.

Может всё уже изменилось, я же не слежу за темой.

спасибо за инфу

нужно добавить т.к. мы не бизнес - основное надежность(ответственность) - поэтому консоль+человек в нашей практике недопустимо - используем ansible + docker для полной автоматизации действий на инфраструктуре - подрядчики только подготовка playbook + dockerfile на дев

за 2019+2020 Аварий на prod была только одна - затопило серверную.
в 2018 в середине года при настройке PG подрядчик сделал  "chmod -R 755 /", вот тогда мы вздрогнули

По умолчанию стоит использовать реляционную модель (дополнительную таблицу) — потом и работать с ней проще.