псевдоним

   Альтернативное имя, заменяющее имя_таблицы. Когда указывается этот псевдоним, он полностью скрывает реальное имя таблицы. Это особенно полезно, когда в предложении ON CONFLICT DO UPDATE фигурирует таблица с именем excluded, так как без определения псевдонима это имя будет отдано специальной таблице, представляющей строки, предназначенные для добавления.

INSERT INTO distributors (did, dname)
   VALUES (5, 'Gizmo Transglobal'), (6, 'Associated Computing, Inc')
   ON CONFLICT (did) DO UPDATE SET dname = EXCLUDED.dname;

https://postgrespro.ru/docs/postgresql/12/sql-insert

версия 9.6
   insert into score.stats_favorite(favorite_cnt, geo, tournament_obj_id) VALUES (1, _geo, _trn_name)
   on conflict (tournament_obj_id, geo, date_create) do update
       set
           favorite_cnt = excluded.favorite_cnt +1
   returning stats_favorite_id into _stats_favorite_id;
не спасает

ну тут мы получаем дублирование всяких служебных структур в памяти, это копейки по идее

и каждый инстанс теперь пишет свой WAL

просто иногда это удобно, например можно каждый инстанс разместить на отдельных дисках, они не будут толкаться за io и проблема с нехваткой места на инстансе. это просто фантазии.

вообщем менеджмент усложнится, теперь не один инстанс надо мониторить и бэкапить, а 5

конечно, ресурсы между инстансами теперь можно распределять гораздо эффективнее

еще есть идеи господа?

favorite_cnt = score.stats_favorite.favorite_cnt +1

вы ошибку хоть напишите.

Это понятно,что сломать можно все, но кластер требуют и вариантов развития событий мало.

[42702] ERROR: column reference "favorite_cnt" is ambiguous

в обоих местах полный путь укажи

патрони нормально работает

а у вас случайно нет такой переменной? я так понимаю это где то из функции вызывается

Понял. Спасибо,буду тестить

таже ошибка
..
нет переменные все идут с _{name}

тестить обязательно

Григорий, но иметь один инстанс на одну БД - это тоже не самое правильное решение

вы из РБ?