Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
обьясните плз, конкурентные в запросы в рамках одного конекта
|
|||
|---|---|---|---|
|
#18+
добрый день, подскажите плз, в рамках одного подключения к БД (одна сессия pg_backend_pid), если первый запрос еще выполняется (не вернул ответа), будет ли паралельно выполнен второй запрос в очереди в данном конекте? Либо он дождется пока не выполнится предыдущий запрос, и только потом будет исполнится? Драйвер подключения, допустим, libpq Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2016, 18:37 |
|
||
|
обьясните плз, конкурентные в запросы в рамках одного конекта
|
|||
|---|---|---|---|
|
#18+
Orinдобрый день, подскажите плз, в рамках одного подключения к БД (одна сессия pg_backend_pid), если первый запрос еще выполняется (не вернул ответа), будет ли паралельно выполнен второй запрос в очереди в данном конекте? Либо он дождется пока не выполнится предыдущий запрос, и только потом будет исполнится? Драйвер подключения, допустим, libpq Спасибо. >> он дождется пока не выполнится предыдущий запрос, и только потом будет исполнится только так и никак иначе. Более того вы через libpq штатно и не сможете второй запрос отправить пока не получили ответ на первый. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2016, 19:15 |
|
||
|
обьясните плз, конкурентные в запросы в рамках одного конекта
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Максим, спасибо большое! Можете проконсультировать, Если рассматривать "классическое" клиент-серверное приложение, насколько целесообразно использовать принцип: один клиент - одна сессия? Из возможных плюсов- если на сервере мы знаем pg_backend_pid клиента, мы можем его использовать при временном хранении данных по этой сессии, использовать временные таблицы в рамках этой сессии. Из минусов - конект лочится, пока не придут результаты, запросы к серверу посылаем последовательно. А какие еще есть минусы у такого подхода? (одна сессия на одно клиентское приложение) ? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 13:21 |
|
||
|
обьясните плз, конкурентные в запросы в рамках одного конекта
|
|||
|---|---|---|---|
|
#18+
OrinMaxim Boguk, Максим, спасибо большое! Можете проконсультировать, Если рассматривать "классическое" клиент-серверное приложение, насколько целесообразно использовать принцип: один клиент - одна сессия? Из возможных плюсов- если на сервере мы знаем pg_backend_pid клиента, мы можем его использовать при временном хранении данных по этой сессии, использовать временные таблицы в рамках этой сессии. Из минусов - конект лочится, пока не придут результаты, запросы к серверу посылаем последовательно. А какие еще есть минусы у такого подхода? (одна сессия на одно клиентское приложение) ? Спасибо! Если сессий ожидается 1-10-(максимум 100) - то минусов никаких. Если вопрос про 100+ одновременных сессий - то надо понимать что 1 коннект у pg - штука очень дорогая и по памяти и по прочим ресурсам и в таких случаях надо пул коннектов использовать а не 1 клиент - 1 сессия. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 13:28 |
|
||
|
обьясните плз, конкурентные в запросы в рамках одного конекта
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, спасибо еще раз! Конектов на одну базу - 30~50 Баз на сервере ~10 (идентичные, отличаются данными) Насколько рационально вданном случае использовать сессию бд? Сейчас есть пулинг, т.е. 1 клиент не владеет выделенным коннектом. Сейчас на клиенте генерируется определенный client_id, который передается с каждым запросом в базу, для идентификации клиента. Но есть неудобство в использовании временных таблиц, но самое неудобное - между процедурами приходится передавать этот client_id. Как вариант можно наверно попробовать использовать set local в рамка транзакции. Т.е. попробовать всю работу по обработке клиентского запроса проводить в рамках одной транзакции. внутри которой вызывать нужные процедуры без параметра client_id, а пробовать получать из локального параметра, установленной "родительской" транзакцией. Но насколько это жизнеспособно пока под вопросом (если вообще возможно) Спасибо за консультацию! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 13:49 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39340779&tid=1996907]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
29ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 283ms |
| total: | 408ms |

| 0 / 0 |
