Вы можете при старте сессии в коннекте колбеке пгбаунсера создавать временную таблицу, тогда клиентам она сразу будет доступна

а можно как то без pgbouncer?

Ну триггер на сторное бд, что вот создалася сессия, значит создавай временную таблицу

А сверяли-то Вы его с чем? ;)

Когда то делал голые запросы через psql сегодня как доберусь посмотрю

Можете тогда с приложения при установке соединения ещё и инит sql свой делать

а можно как то без pgbouncer?

On LOGON TRIGGER? Или это я разбежался?

On LOGON TRIGGER? Или это я разбежался?

On login тогда? Ну вариант, просто я не знал что такой есть :)

Или эмулировать временные Таблицы на постоянных и использую txcurrent

On login тогда? Ну вариант, просто я не знал что такой есть :)

Такого нет

Жаль!

Вы можете при старте сессии в коннекте колбеке пгбаунсера создавать временную таблицу, тогда клиентам она сразу будет доступна

У pgbouncer есть возможность определять коллбек при старте сессии?

txid_current()

Жаль!

Разве это не зависит от режима pgbouncer? Кажется, в session level pooling временные таблицы по умолчанию DROP-аются по завершении сессии.

У pgbouncer есть возможность определять коллбек при старте сессии?

Конечно

Разве это не зависит от режима pgbouncer? Кажется, в session level pooling временные таблицы по умолчанию DROP-аются по завершении сессии.

Конечно

Конечно

ссылкой не поделитесь, а то никак нагуглить не могу

Ладно, в которой раз придеться юзать UNLOGGED вместо TEMP :)

Все никак не могу придумать, как TEMP таблицы заюзать :)

Но ведь временные таблицы можно использоватьс pgbouncer-ом только в режиме session level pooling! А толку от такого режима мало. Его можно использовать когда есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение. Но это по любому ошибка дизайна. А нужен pgbuncer в первую очередь когда есть много умных клиентов, но лишь некоторые из них одновеременно активны. В таком случае нужно использовать statement level pooling и временные таблицы использовать нельзя.

ссылкой не поделитесь, а то никак нагуглить не могу

connect_query в конфиге

Спасибо!

Но ведь временные таблицы можно использоватьс pgbouncer-ом только в режиме session level pooling! А толку от такого режима мало. Его можно использовать когда есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение. Но это по любому ошибка дизайна. А нужен pgbuncer в первую очередь когда есть много умных клиентов, но лишь некоторые из них одновеременно активны. В таком случае нужно использовать statement level pooling и временные таблицы использовать нельзя.

Костя, а почему для транзакций то нельзя?!

Для транзакции можнопри использовании transaction level pooling. То тогда и каллбак при старте session не нужен. Создаёшь таблицу в начале транзакции и кдаляешь в конце... И получаешь в результате catalog bloating.

Но ведь временные таблицы можно использоватьс pgbouncer-ом только в режиме session level pooling! А толку от такого режима мало. Его можно использовать когда есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение. Но это по любому ошибка дизайна. А нужен pgbuncer в первую очередь когда есть много умных клиентов, но лишь некоторые из них одновеременно активны. В таком случае нужно использовать statement level pooling и временные таблицы использовать нельзя.

А почему Вы считаете, что это ошибка дизайна?

Но ведь временные таблицы можно использоватьс pgbouncer-ом только в режиме session level pooling! А толку от такого режима мало. Его можно использовать когда есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение. Но это по любому ошибка дизайна. А нужен pgbuncer в первую очередь когда есть много умных клиентов, но лишь некоторые из них одновеременно активны. В таком случае нужно использовать statement level pooling и временные таблицы использовать нельзя.

это понятно. С pgbouncer и его политикой коммитов отдельный вопрос, не понятно как выставлять схему например и прочие сесионные параметры

pgbouncer вообще раздражает, он периодически, без надобности, просто убивает разогретые tcp соединения в режиме commit

>А почему Вы считаете, что это ошибка дизайна? Ну потому что установление коннекта - это очень дорогая операция. Конечно бывают ситуации, когда без этого никак. Но в большинтсве случаев всё таки лучше открыть коннекшин один раз и держать пока он нужен.

>А почему Вы считаете, что это ошибка дизайна? Ну потому что установление коннекта - это очень дорогая операция. Конечно бывают ситуации, когда без этого никак. Но в большинтсве случаев всё таки лучше открыть коннекшин один раз и держать пока он нужен.

ага, а pgbouncer обрубает коннекты по расписанию с базой

Для транзакции можнопри использовании transaction level pooling. То тогда и каллбак при старте session не нужен. Создаёшь таблицу в начале транзакции и кдаляешь в конце... И получаешь в результате catalog bloating.

Можно в начала сессии создавать

На коннект_квери

У человека видимо нет доступа

Как у разраба приложения

> не понятно как выставлять схему например и прочие сесионные параметры 1. Никак. Зачем их выставлять? Т.е. зачем клиенту могут потребоваться какие-то специфичные только для него установки? Разве что только роль задать... 2. Все установки (set xyz=XXX) конкатенировать в строчку и добавлять это строку в качестве префикса к каждому statement-у через ';'

ага, а pgbouncer обрубает коннекты по расписанию с базой

пересоздавать периодически по расписанию простаивающий коннекты - это норма, даже лучше чем просто всё время держать

пересоздавать периодически по расписанию простаивающий коннекты - это норма, даже лучше чем просто всё время держать

он не простаивающие убивает

а рабочие!

а рабочие!

хм, странно

хм, странно

вот и я о том же

а рабочие!

А вот это либо баг, либо надо разбираться.

А вот это либо баг, либо надо разбираться.

По моему это фича как раз

server_connect_timeout

По моему это фича как раз

Я такого не помню на проектах с различным объемом данных, с различной нагрузкой и различным временем запросов.

Я такого не помню на проектах с различным объемом данных, с различной нагрузкой и различным временем запросов.

значит был сессионный режим

а не коммитный

при сессионном он держит соединение

>Можно в начала сессии создавать Какие сессии в режиме statement/transaction pooling? Я не спец по pgbouncer-у. Я с другой стороны в осонвном лазил:) temporary табличка живёт в бэкенде. pgbouncer в режиме отличном от session pooling разбрасывает запросы по разным бэкендам. Я не могу себе представить как бы можно было создать временную табличку в начале сессии и и потом использовать её на любом бэкенде. Даже если pgbouncer поддерживает некий каллбэк, который будет выполняться пере выполнением запроса или транзакции на каждом бэкенде, то всё равно данные временной таблички между бэкендами никто не передаст.

И надо понимать, что обрывает он не соединение между клиентом и pgbouncer, а соединение между pgbouncer и postgres

Т.е. если у тебя нет сессионных параметров, то ты этого и не заметишь

>Можно в начала сессии создавать Какие сессии в режиме statement/transaction pooling? Я не спец по pgbouncer-у. Я с другой стороны в осонвном лазил:) temporary табличка живёт в бэкенде. pgbouncer в режиме отличном от session pooling разбрасывает запросы по разным бэкендам. Я не могу себе представить как бы можно было создать временную табличку в начале сессии и и потом использовать её на любом бэкенде. Даже если pgbouncer поддерживает некий каллбэк, который будет выполняться пере выполнением запроса или транзакции на каждом бэкенде, то всё равно данные временной таблички между бэкендами никто не передаст.

Не запросы, а транзакции

Но по факту он именно так и делает

Т.е. убивает наиболее загруженные коннекты, между pgbouncer и postgres

Т.е. убивает наиболее загруженные коннекты, между pgbouncer и postgres

Вы смеётесь что ли?! пгбаунсер один из самых надёжных серверов что я видел . Он работает отлично на запредельных нагрузках

значит был сессионный режим

Вот это вот я не помню, врать не буду.

Вы смеётесь что ли?! пгбаунсер один из самых надёжных серверов что я видел . Он работает отлично на запредельных нагрузках

А я это оспариваю? Это у него фича такая

Он обрывает по таймауту содениение между pgbouncer и postgres

и не важно, нагруженное оно или нет было

>А почему Вы считаете, что это ошибка дизайна? Ну потому что установление коннекта - это очень дорогая операция. Конечно бывают ситуации, когда без этого никак. Но в большинтсве случаев всё таки лучше открыть коннекшин один раз и держать пока он нужен.

Хмм... а зачем держать ненужное соединение? Это же тоже стоит ресурсов.

Он обрывает по таймауту содениение между pgbouncer и postgres

тут вопрос: коннект обрывается, когда он освобождён и находится в пуле, или когда он занят внешним клиентом? По-хорошему imho, даже если таймаут сработал в момент занятости коннекта, то он должен подождать пока освободиться и потом пересоздать свою сессию

тут вопрос: коннект обрывается, когда он освобождён и находится в пуле, или когда он занят внешним клиентом? По-хорошему imho, даже если таймаут сработал в момент занятости коннекта, то он должен подождать пока освободиться и потом пересоздать свою сессию

По хорошему я тоже так считаю, но он его обрубует в любом случае. Не во время транзакции конечно, но сразу после нее

По хорошему я тоже так считаю, но он его обрубует в любом случае. Не во время транзакции конечно, но сразу после нее

даже при сессионном пуллинге?

даже при сессионном пуллинге?

Нет, при сессионном все ок

Речь о коммитном пуллинге

ну тогда всё норм, после транзакции коннект потенциально свободен

ну тогда всё норм, после транзакции коннект потенциально свободен

да, но tcp соединение уже разогрето, на очереди следующие данные

а оно обрывается

да, но tcp соединение уже разогрето, на очереди следующие данные

tcp между клиентом баунсером?

нет

между bouncer и postgres

что еще хуже

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

Если соединение ненужное, то и держать его не нужно:) Что значит "не нужное"? Это значит в течение нескольких секунд к базе никто не полезет. Тогда его ес-но можно дропнуть. Но тогда и pgbouncer не особо нужен. Если же клиент сразу же захочет отправить ещё один запрос, то рвать и переустанавливать соединение очень глупо. Ес-но мы (приложение) часто не знаем намерения клиента. Может он пошлёт запрос сейчас же. А может ушёл обедать. В таком случае лучше всего наверное рвать коннекшин по таймауту. Я только хочу сказать, что session level pooling в pgbouncer-е не спасёт о того, что вернушись с обеда несколько тысяч клиентов олдновременно захотят обратится к базе, что потребует запуска Посгресом нескольких тысяч процессов-бэкендов (если в pgbouncer-а не ограничено максимальное число коннектов). А если ограничено - то тогда некторые клиенты просто не смогут достучаться до базы.

между bouncer и postgres

ну тут диллема, что выгоднее: удержать разогретый tcp или убить разбухший бекэнд сессии

> не понятно как выставлять схему например и прочие сесионные параметры 1. Никак. Зачем их выставлять? Т.е. зачем клиенту могут потребоваться какие-то специфичные только для него установки? Разве что только роль задать... 2. Все установки (set xyz=XXX) конкатенировать в строчку и добавлять это строку в качестве префикса к каждому statement-у через ';'

Ну вот timezone, например.

Если соединение ненужное, то и держать его не нужно:) Что значит "не нужное"? Это значит в течение нескольких секунд к базе никто не полезет. Тогда его ес-но можно дропнуть. Но тогда и pgbouncer не особо нужен. Если же клиент сразу же захочет отправить ещё один запрос, то рвать и переустанавливать соединение очень глупо. Ес-но мы (приложение) часто не знаем намерения клиента. Может он пошлёт запрос сейчас же. А может ушёл обедать. В таком случае лучше всего наверное рвать коннекшин по таймауту. Я только хочу сказать, что session level pooling в pgbouncer-е не спасёт о того, что вернушись с обеда несколько тысяч клиентов олдновременно захотят обратится к базе, что потребует запуска Посгресом нескольких тысяч процессов-бэкендов (если в pgbouncer-а не ограничено максимальное число коннектов). А если ограничено - то тогда некторые клиенты просто не смогут достучаться до базы.

опять вы меня не поняли. Соединение нагруженное, данные идут постоянно. Но по таймауту оно обрубается железно!

ну тут диллема, что выгоднее: удержать разогретый tcp или убить разбухший бекэнд сессии

не вижу дилеммы. По мне дак вообще нельзя убивать коннекты между pgbouncer и postgresql

не вижу дилеммы. По мне дак вообще нельзя убивать коннекты между pgbouncer и postgresql

тогда у бекэндов будет разбухать локальная память

> Соединение нагруженное, данные идут постоянно. Но по таймауту оно обрубается железно! А зачем тогда использовать pgbouncer?

тогда у бекэндов будет разбухать локальная память

он что, течёт чтоли? :=)

он что, течёт чтоли? :=)

формально нет, но всё же

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

а частое выделение памяти - тоже проблема.

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

памяти будет меньше однозначно, наблюдал это не раз

>тогда у бекэндов будет разбухать локальная память Память может разбухать либо если в Посгресе есть memory leak-и, либо у нас очень большой каталог изи-за чего локальные кэши могут раздуваться. Но это корее клинический случай. Опять таки если в базе сотни тысяч ьтаблиц, то покупайте под неё машинку с большим колличеством памяти, чтобы радувающиейся бэкенды в неё влезали. Потому как если каталог ен влезает в кэш, это по любому очень плохо будет сказываться на скорости.

он что, течёт чтоли? :=)

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

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

проблема в том, что work_mem работает только на этапе планирования

а частое выделение памяти - тоже проблема.

что значит частое?

а так проблемы нет.

проблема в том, что work_mem работает только на этапе планирования

поэтому проблемы могут быть с oom если плохая статистика

Не должны бэкенды дуться. Чаще вссего это свидетельствует о каких-то проблемах с приложением: слишком много вреенных таблиц, prepared statement-ов,...

проблема в том, что work_mem работает только на этапе планирования

work mem как я понимаю высвобождается, речь не о нём. В принципе, мажоритарно у бекэндов, которые долго живут, resident anonymous часть разрастается

Не должны бэкенды дуться. Чаще вссего это свидетельствует о каких-то проблемах с приложением: слишком много вреенных таблиц, prepared statement-ов,...

ну в том числе

work mem как я понимаю высвобождается, речь не о нём. В принципе, мажоритарно у бекэндов, которые долго живут, resident anonymous часть разрастается

объясняю, если work_mem достаточен на этапе планирования, то операция производиться делается в памяти - тогда может произойти OOM, если планировщик неодооценил кол-во строк. это проблема. а то что бакэнд кушает память и вышел на "крейсерное значение" - это не проблема

Есть ещё кончено франгментация памяти. С которой аллокаторы борются борются но никак не поборют. Но Посгресовые MemoryContext-ы всё таки должны сильно уменьшать фрагментацию.

Да, oom может случиться из-за прокола с планом. Но перезапуск бэкенда тут ен поможет. Это может случиться и на свеженьком бэкенде.

опять вы меня не поняли. Соединение нагруженное, данные идут постоянно. Но по таймауту оно обрубается железно!

Да я не совсем об этом... А почему бы не рассчитывать на то, что установление соединения "дешёвое" (т.е. рассчитывать на bouncer)? Т.е. сделал дело (транзакцию, например; или стало известно, что оно в ближайшее время не понадобится) —- закрыл соединение (в приложении)?

> Соединение нагруженное, данные идут постоянно. Но по таймауту оно обрубается железно! А зачем тогда использовать pgbouncer?

Как зачем? Несколько разогретых соединений с постгресом и куча с боунсером

Потому что установление TCP-шного соединения (хотя с pgbouncer-ом, хоть с кем либо ещё) по любому не дешёвая операция.

Да я не совсем об этом... А почему бы не рассчитывать на то, что установление соединения "дешёвое" (т.е. рассчитывать на bouncer)? Т.е. сделал дело (транзакцию, например; или стало известно, что оно в ближайшее время не понадобится) —- закрыл соединение (в приложении)?

Закрытие соединения в приложении не влияет на дисконнект баунсера с постгресом. Да и установка соединения дорогая операция

объясняю, если work_mem достаточен на этапе планирования, то операция производиться делается в памяти - тогда может произойти OOM, если планировщик неодооценил кол-во строк. это проблема. а то что бакэнд кушает память и вышел на "крейсерное значение" - это не проблема

work_mem вообще мало помогает, если сложность планов непредсказуема.