смешивать таблицы и объекты - плохая идея, в первую очередь потому что на практике реальный объект описывается комбинацией разных таблиц, и клиенту совершенно не интересно как он хранится в бд и почему именно так, как его туда сохранять. Это только в простых и маленьких ис можно напрямую мапить объекты вроде юзера на таблицы. У меня например юзер это десяток разных таблиц. И когда клиент споашивает, он вполне комфортно сшивается и отдается. А когда нужна часть юзера - отдается или меняется эта часть, другая даже не блокируется. Инкапсуляция хранения структуры внутри бд, и влияния логики изменения юзера на другие таблицы, полиморфизм юзеров, наследование через добавление свойств и методов доступа к новым типам юзеров. Кажется это и называется ооп, не так ли? Попытка натянуть ооп непосредственно на таблицы приводит новичков к хранению json полей, со всеми вытекающими побочными эффектами.

Надысь замерял скорость работы новой функции pg_probackup.
Задача - восстановить отставшую реплику, когда нужные WAL уже удалили.
Сделал на одной машине мастер/реплику.
Подал небольшую нагрузку на мастер таким образом, чтобы изменялась только 1/6 часть базы ( симуляция небольшого количества горячих данных и кучи накопившихся исторических. Соотношение взято от балды ).
Так вот, восстановление реплики с помощью pg_basebackup заняло в среднем 65 минут.
А pg_probackup catchup в режиме PTRACK - около 10 минут.

прикольно, но я пока по старинке )

Самое приятное - надо только ptrack настроенный.
Для самого catchup вообще надо указать только мастер и реплику, которую надо починить.

Не, это ответ в общем, но надо инкапсулировать на уровне БД.  Я с этим не согласен, я думаю что инкапсуляция должны быть на более высоком уровне, чтобы обеспечить переносимость на другие БД. Но вопрос бы не про это. Вот вы ракладываете вашего кастомера по куче таблиц строго следуя реляционной модели. Но PG поддерживает и ОО. Т.е. вообще говоря, если правильно описать типы, можно все атрибуты юзера сохранить в одной таблице. Т.е чисто замапить OO модель на БД. В NoSQL так и делают, к слову. И гордятся этим 😊. Так вот и вопрос: где нибудь эти фичи PG используются как основа архитекруты или они на самом деле лишние?

Чей-то у меня буквы пропадают. Пальцы замерзли печатать 😊

чтобы обеспечить переносимость на другие БД

чего?

Приложения.

всем привет подскажите как раскрыть array в execute '' ?
execute' select unnest( '|| _areas ||' ) as areas'

так почему то не работает

Этот тот execute, который в pl/pgsql?
Тогда замените его на raise notice и посмотрите что там за строчка получается.

да он самый который в функии
> ERROR:  malformed array literal: "
-select unnest(array[80,124]) areas
select unnest("
LINE 1: SELECT '

массив вот так вызывается {87,77}
хотя должен по идеи в обычных скобках  select unnest(array[1,2,3])

select unnest ({87,77})

вот так показывает нотисе

Сам по себе этот запрос из нотиса работает?

нет

Всяко кавычки надо поставить куда-то.

вообщем как раскрыть массив в конструкции execute

?

В execute надо передать корректный запрос. Если он у вас не выполняется сам по себе - дело не в execute, а в запросе.

Такой вопрос: есть две таблицы которые соединяются через join и результат надо отсортировать по полю, которое одинаково называется в обеих таблицах.  При попытке указать это поле в order by выдается ошибка  "ambiguous". Можно, конечно, явно переименовать. Но может быть есть какое-то правило как такие поля именуются по дефолту? Префикс какой то?