p
Потому что пул соединений находится не со стороны базы а со стороны клиента
Это очень неудобное решение
Size: a a a
2019 November 10
VO
Это да, а если бэкенд серверов, скажем, 1000? В хайлоаде это встречается. Даже если каждый инстанс приложения будет держать по 1 постоянному соединению к PostgreSQL, будет плохо.
т.е. сервер со своей стороны должен перекидывать удаленный конец сокета? Или что?
VO
Это очень неудобное решение
архитектура tcp тебе другого не позволяет.
p
архитектура tcp тебе другого не позволяет.
Причем тут tcp?
VO
Причем тут tcp?
а что, сессия у нас святым духом?
MZ
Давайте проведем опрос, кто-нибудь, использующий pg в вебе задумывается, что там collaction может внезапно быть разный, да и вообще об этом? И я субъективно уверен, что вдруг окажется нужным об этом поговорить. А те, кто задумывался, небось имеют набор костылей и подпорок. Там в 9-ке какой-то плагин был специальный
Есть еще японские внедрения pg/oracle поверх linux/windows с кодировками half/full-width символов. Если кратко, то пришлось на уровне application-а доразруливать ряд краевых моментов (к примеру арабские цифра 1 иногда должны быть таки различной в half/full изза особенностей прописания адресов в документах аля паспорта) .
p
а что, сессия у нас святым духом?
af_unix, например
VO
тогда у тебя нет проблемы с 1000 бакенд-серверов
p
тогда у тебя нет проблемы с 1000 бакенд-серверов
У нас какой-то разговор слепого с глухим.
Речь о том, почему не поставлять pgbouncer из коробки
Речь о том, почему не поставлять pgbouncer из коробки
VO
понятия не имею, может просто кто-то кого-то очень не любит?
A
Кажется, что-то очень близкое рассказывал в четверг Иван Панченко, типа из коробки идёт мало всего, а энтерпрайз требует, так что, будем надеяться, жизнь упростится
Y
т.е. сервер со своей стороны должен перекидывать удаленный конец сокета? Или что?
Нет, но серверу хорошо бы уметь обрабатывать соединения отдельно от создания процесса, чтобы 1000 коннектов не приводили к созданию 1000 процессов PostgreSQL. То есть иметь разделение на "пул соединений" и "пул воркеров" на стороне сервера. Сейчас эту роль выполняет pgBouncer, но, повторюсь, тот же MySQL или MongoDB прекрасно справляются и без дополнительных прокси.
VO
нет, я так не считаю.
VO
давайте еще говорить что апач надо написать так же как nginx и он будет такой же быстрый
Y
нет, я так не считаю.
Вы не считаете, что это реальная проблема в хайлоад окружении, или не согласны с предлагаемым решением?
VO
если уж начинать, то с определений.
проблема -- то что требует решения и не решено, но решаемо. pg_bouncer есть? есть. всё, вычеркиваем -- это не проблема.
а предложенно не решенение, а вообще какая-то маниловщина.
проблема -- то что требует решения и не решено, но решаемо. pg_bouncer есть? есть. всё, вычеркиваем -- это не проблема.
а предложенно не решенение, а вообще какая-то маниловщина.
H
давайте еще говорить что апач надо написать так же как nginx и он будет такой же быстрый
* набрасывает *
апач такой же быстрый как и nginx
Я его тюнил
апач такой же быстрый как и nginx
Я его тюнил
PK
Как там разный колатион? Или у тебя в проекте 23-х летний архитектор?
5 лет назад у Ubuntu и FreeBSD точно был разный. Причем я не не уверен про разные дистрибутивы Linux - просто даже не стал изучать вопрос, поняв, чито UCA мне без заката Солнца вручную не будет
VO
5 лет назад у Ubuntu и FreeBSD точно был разный. Причем я не не уверен про разные дистрибутивы Linux - просто даже не стал изучать вопрос, поняв, чито UCA мне без заката Солнца вручную не будет
я тебя не понимэ, у тебя в постгресе хранится ubuntu и freebsd? или где?
PK
я тебя не понимэ, у тебя в постгресе хранится ubuntu и freebsd? или где?
Нет, постгрес использует системные коллэйшн