А почему pgbouncer не может после каждого PREPARE который он выполняет в одной из сессий, автоматически выполнить тот же PREPARE в остальных сессиях, это же просто! Как только получил на любой PREPARE ответ без ошибки, сразу добавить в очередь всех других сессий этот же запрос чтобы в них создались такие же стейтменты. Это уже можно делать асинхронно, но главное добавлять в очередь перед тем как отправить клиенту ответ, чтобы остальные PREPARE гарантированно отработали во всех сессиях до попадания в них EXECUTE с тем же именем. Можно еще сделать мапинг client_name -> bouncer_name чтобы при отрыве клиента удалять все его PREPARE во всех сессиях, через этот мапинг так же подменять все имена для EXECUTE.
@@МаксМаксимов-ш7э Если приходит приличная пачка запросов, то унылый пг будет поднимать отдельный процесс под каждое новое соединение, запросы будут отваливаться по таймауту
Очень плохо, начиная со snake_case в коде Го, паник, которые "не надо использовать", про работу драйвера БД, "в Го есть пул соединений" и прочие перлы вообще молчу. Блять, и половина доклада про какую-то левую библиотеку, смысл которой это чтобы не дай бог не написать пару лишних строчек кода, аля чтобы все было как в уютненьком PHP.
Отличный доклад, все по делу. Спасибо!
Мне как раз это сейчас нужно.!
Спасибо за видео, очень полезно!
Как называется либа которая делает emulate prepared statements?
1:54 - объясните, почему отсутствие ORM - это сила языка?
Тоже хотел бы понять) все гоферы об этом говорят, но никто почему
@@yodapunishes потому что "зумеров" не приходится обучать SQL, им приходится его изучать
спасибо за доклад
отличный доклад
А почему pgbouncer не может после каждого PREPARE который он выполняет в одной из сессий, автоматически выполнить тот же PREPARE в остальных сессиях, это же просто! Как только получил на любой PREPARE ответ без ошибки, сразу добавить в очередь всех других сессий этот же запрос чтобы в них создались такие же стейтменты. Это уже можно делать асинхронно, но главное добавлять в очередь перед тем как отправить клиенту ответ, чтобы остальные PREPARE гарантированно отработали во всех сессиях до попадания в них EXECUTE с тем же именем. Можно еще сделать мапинг client_name -> bouncer_name чтобы при отрыве клиента удалять все его PREPARE во всех сессиях, через этот мапинг так же подменять все имена для EXECUTE.
pg не держит более 100 коннектов?
Пых не поддерживает пул соединений?
Одного Bouncer-а может не хватать?
100 коннектов - гипербола, про баунсеры всё достаточно ясно сказано (одного баунсера может не хвататать dba.stackexchange.com/a/155739)
тоже не понял, у меня 300 коннектов работает без баунсера, почему несколько баунсеров надо ставить я не понял.
Сам раз работчик PG не рекомендует больше 100 коннектов
@@winfle но объяснения нет
@@МаксМаксимов-ш7э Если приходит приличная пачка запросов, то унылый пг будет поднимать отдельный процесс под каждое новое соединение, запросы будут отваливаться по таймауту
Отличный спич
Был свидетелем. Открывал лк, видел чужой акк. дальше новый акк при обновлении.
ничего себе, в 21м веке яп умеет работать с бд и для этого нужен доклад. Вот это хайлоад не по годам.
Какойто стремный и костыльный язык, аля нам надоел пхп в авито, хотим геморроя, давайте перейдем на го
Люблю объективные аргументы
Очень плохо, начиная со snake_case в коде Го, паник, которые "не надо использовать", про работу драйвера БД, "в Го есть пул соединений" и прочие перлы вообще молчу. Блять, и половина доклада про какую-то левую библиотеку, смысл которой это чтобы не дай бог не написать пару лишних строчек кода, аля чтобы все было как в уютненьком PHP.
Вообще так-то смысл любой библиотеки в том чтобы не писать какое-то количество лишних строчек кода
Да, всё говно, кэш на чтение в редиске или мемкэше нет не слышал? - все запросы в базу уникальны?
Лол.
чет чуш