Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / обьясните плз, конкурентные в запросы в рамках одного конекта / 5 сообщений из 5, страница 1 из 1
02.11.2016, 18:37
    #39340239
Orin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
обьясните плз, конкурентные в запросы в рамках одного конекта
добрый день,

подскажите плз, в рамках одного подключения к БД (одна сессия pg_backend_pid),
если первый запрос еще выполняется (не вернул ответа), будет ли паралельно выполнен второй запрос в очереди в данном конекте?
Либо он дождется пока не выполнится предыдущий запрос, и только потом будет исполнится?

Драйвер подключения, допустим, libpq

Спасибо.
...
Рейтинг: 0 / 0
02.11.2016, 19:15
    #39340269
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
обьясните плз, конкурентные в запросы в рамках одного конекта
Orinдобрый день,

подскажите плз, в рамках одного подключения к БД (одна сессия pg_backend_pid),
если первый запрос еще выполняется (не вернул ответа), будет ли паралельно выполнен второй запрос в очереди в данном конекте?
Либо он дождется пока не выполнится предыдущий запрос, и только потом будет исполнится?

Драйвер подключения, допустим, libpq

Спасибо.

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

только так и никак иначе. Более того вы через libpq штатно и не сможете второй запрос отправить пока не получили ответ на первый.

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
03.11.2016, 13:21
    #39340750
Orin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
обьясните плз, конкурентные в запросы в рамках одного конекта
Maxim Boguk,

Максим, спасибо большое!

Можете проконсультировать,

Если рассматривать "классическое" клиент-серверное приложение, насколько целесообразно использовать принцип:
один клиент - одна сессия?

Из возможных плюсов- если на сервере мы знаем pg_backend_pid клиента, мы можем его использовать при временном хранении данных по этой сессии, использовать временные таблицы в рамках этой сессии.

Из минусов - конект лочится, пока не придут результаты, запросы к серверу посылаем последовательно.

А какие еще есть минусы у такого подхода? (одна сессия на одно клиентское приложение) ?




Спасибо!
...
Рейтинг: 0 / 0
03.11.2016, 13:28
    #39340756
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
обьясните плз, конкурентные в запросы в рамках одного конекта
OrinMaxim Boguk,

Максим, спасибо большое!

Можете проконсультировать,

Если рассматривать "классическое" клиент-серверное приложение, насколько целесообразно использовать принцип:
один клиент - одна сессия?

Из возможных плюсов- если на сервере мы знаем pg_backend_pid клиента, мы можем его использовать при временном хранении данных по этой сессии, использовать временные таблицы в рамках этой сессии.

Из минусов - конект лочится, пока не придут результаты, запросы к серверу посылаем последовательно.

А какие еще есть минусы у такого подхода? (одна сессия на одно клиентское приложение) ?




Спасибо!

Если сессий ожидается 1-10-(максимум 100) - то минусов никаких.
Если вопрос про 100+ одновременных сессий - то надо понимать что 1 коннект у pg - штука очень дорогая и по памяти и по прочим ресурсам и в таких случаях надо пул коннектов использовать а не 1 клиент - 1 сессия.

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
03.11.2016, 13:49
    #39340779
Orin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
обьясните плз, конкурентные в запросы в рамках одного конекта
Maxim Boguk,

спасибо еще раз!

Конектов на одну базу - 30~50
Баз на сервере ~10 (идентичные, отличаются данными)
Насколько рационально вданном случае использовать сессию бд?


Сейчас есть пулинг, т.е. 1 клиент не владеет выделенным коннектом.

Сейчас на клиенте генерируется определенный client_id, который передается с каждым запросом в базу, для идентификации клиента.

Но есть неудобство в использовании временных таблиц, но самое неудобное - между процедурами приходится передавать этот client_id.

Как вариант можно наверно попробовать использовать set local в рамка транзакции. Т.е. попробовать всю работу по обработке клиентского запроса проводить в рамках одной транзакции. внутри которой вызывать нужные процедуры без параметра client_id, а пробовать получать из локального параметра, установленной "родительской" транзакцией. Но насколько это жизнеспособно пока под вопросом (если вообще возможно)

Спасибо за консультацию!
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / обьясните плз, конкурентные в запросы в рамках одного конекта / 5 сообщений из 5, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]