9404
Чат русскоязычного сообщества PostgreSQL, здесь мы обсуждаем технические вопросы, для поиска работы и предложения вакансий есть группа https://t.me/pgsqljobs For English discussion visit https://t.me/pg_sql
Это тоже противоречит ТЗ. По ТЗ человек хочет продолжать на listen/notify
Читать полностью…
Есть replication slot, если уж так хочется изменения в каких-то таблицах ловить
Читать полностью…
Ну как бы
— Ася! Когда мой муж делает так — у него рвутся рубашки. Как быть?
— Так вы не делайте так
ладно, не суть, тут скорее интересно было в чем прикол, понятно что надо менять решение
Читать полностью…
https://www.recall.ai/blog/postgres-listen-notify-does-not-scale
вот тут рассказывают
Т.е тормозить может не отправка уведомлений, а тот кто очередь разгребает. Если он не успевает, то в очередь нельзя будет засунуть данные
Читать полностью…
Может очередь просто переполняется? Notify будет их ждать
Читать полностью…
Механизм listen/notify шлёт уведомление когда завершылась транзакцыя, код в которой вызвал notify.
Изменились ли там где данные — это вопрос к вашым программам, которые вызвали notify.
Что подвисает-то? Как дифференцировали тормоза системных таблиц от тормозов пользовательских?
Читать полностью…
я не мастер по постгре, но когда срабатывает notify, создается глобальный блок системной\ных таблиц, не пользовательских, а именно часть системы подвисает, и соответственно если много записей льется в таблицу тригерную, постгре может поплохеть
Читать полностью…
Добрый день
Вопрос, есть ли способо убрать блоировку системной таблицы когда notify происходит?
Тогда тем более непонятно, зачем ему процедурный язык pgsql из наименования канала )))
Читать полностью…
Тогда и Кафка не поможет, так как Debezium connect сидит именно на них
Читать полностью…
Проблема же не внезапно возникла, значит есть костыль для подпирания пока патч в стабильный релиз не уедет
Читать полностью…
*и да, перевести очереди сообщений на кафку — идея в принцыпе здравая. Независимо от того, кто у вас тормозит.
Дажэ учитывая, что с консистентностью работы будет побольшэ.
Из постгреса с любой стороны не лучшая очередь сообщений.
Гугль — отличный инструмент для поиска известных фактов и новых идей. В том числе по оптимизацыям.
Но решать проблемы производительности своей программной системы гуглением — подход в корне неверный и неработающий. Вы должны измерять скорости и узкие места в СВОЕЙ системе, гугль это не можэт в принцыпе.
ну из того что я нагуглил, пишут чет про блокировку части системы субд, и все
ну по факту похоже нужно просто фв кафку переходить, а начиналось так красиво
Вы проблему-то покажыте. Код, измерения, огыбки, вот это всё.
(Сейчас — это дажэ не рассуждения около, это какие-то абстрактные стенания).
потому что пишется только в путь, нагрузка на машину почти не растет, отправка уведомлений доходит до пары тысяч в секунду и дальше не растет, погуглив нашел что да есть такая проблема, посоветовали перейти на редис или кафку, в зависимости от того что нужно, а мне интересно, неужели не решил эту проблему никто
Читать полностью…
механизм listen\notify, когда видит новые данные в табличке, шлет уведомление, верно?
в момент отправки уведомления, часть самой постгри блочится
и если много данных пишется в таблицу, то самой субд плохеет
в момент отправки уведомления какой-то обработчик так делает, не хочу переезжать на кафку, хочу постгрю как очередь дальше насиловать
Читать полностью…
Ну как бы в названии условное сокращение как я понимаю))(( не язык )
Читать полностью…
Зачем вообще фронтендеру SQL? Им и Datatables должно хватить.
Читать полностью…