Да, если не отловить это исключение, вся транзакция откатится.

Добрый вечер!
Есть вспомогательный  запрос, котрый если left join к основному запросу выполняется за 3.6 сек. Сам по себе вспомогательный за 3мс выполняется. Основной запрос без вспомогательного за 277мс выполняется. При том том что другие связи не дают такого увеличения  времени запроса. В чем может быть дело?

Таблица и очередь в listen/notify решают *разные* задачи. Если делать очередь на таблице, придётся её поллить постоянными селектами и получите минимальную гарантированную латенси даже пустой очереди равную периоду между запросами.
listen/notify решает эту проблему и в комбинации с табличками позволяет снизить латенси до времени ipc на сервере БД. Точнее, если у вас используется не libpq, а, например, стандартный jdbc-клинт, придётся всё равно запросы слать, но это будут пустые запросы, не нагружающие сервер.

есть индекс по соединяемым полям? обычно на FK вешают индексы

Доаолнительно интдексов не делал только ключи

Доброе утро, вы можете помочь мне с этой ошибкой?
Можно было решить только поменяв разрешения?

Для локализации предлагаю выкинуть все остальные таблицы из запроса, оставить минимум, на котором воспроизводится. Потом EXPLAIN ANALYZE (без выкидывания лишнего будет тяжело разбираться). И текстом, не картинкой

Всем привет, подскажите как исключить из select строки, в которых есть дубликат группы значений, например исключить по (id, name) обе строки "2, dupl" :

id, name
1, dupl
2, no_dupl
2, dupl
2, dupl
2, some

Сделать группировку с count() в подзапросе и выбрать из его результата только те строки, где count =1 ?

Спасибо

distinct(id, name) так вроде должно работать

distinct сделает

1  dupl
2  dupl
2  no_dupl
2  some

а надо как я понял

1, dupl
2, no_dupl
2, some

тут group by ... having поможет, как и было сказано выше

всем привет)

можно в пг как то сделать фильтр что строки только lowercase?

чтобы отфильтровало все значения где есть залавная буква

lower/upper

initcap тоже вроде есть