Postgresql - подготовленные операторы против пула соединений - это компромисс?

Question

Насколько я понимаю, вы можете использовать подготовленные операторы или пул соединений (с такими инструментами, как pgPool / pgBouncer) с Postgresql, но можете воспользоваться только одним одновременно ( по крайней мере с драйвером Npgsql для .NET , плюс Автор библиотеки предлагает отключить пул соединений на стороне клиента при использовании PgBouncer ). Я прав?
Если так - это правда для других сред выполнения и языков, таких как Java, Python, Go? Или это проблема конкретной реализации?

Answer 1

Это сложный вопрос, но вот несколько ответов.

Как пишет @ laurenz-albe, вы можете использовать pgbouncer и подготовленные операторы, но нужно использовать пул сеансов. Это позволяет вам использовать подготовленные операторы в течение всего времени вашего соединения (т. Е. Пока ваш экземпляр NpgsqlConnection открыт). Однако, если вы находитесь в кратковременном сценарии подключения (например, веб-приложение, которое открывает и закрывает подключение для каждого HTTP-запроса), вам не повезло. В этом смысле можно сказать, что объединенные и подготовленные операторы несовместимы.

Однако, если вы используете внутренний механизм пула Npgsql (по умолчанию включен) вместо pgbouncer, то ваши подготовленные операторы автоматически сохраняются при открытии / закрытии соединения. Другими словами, когда вы вызываете NpgsqlCommand.Prepare(), если физическое соединение уже подготовило SQL, то подготовленный оператор используется повторно. Это сделано специально для того, чтобы разблокировать преимущества скорости подготовленных операторов для сценариев кратковременного подключения. Это довольно уникальное поведение Npgsql, см. Документацию для получения дополнительной информации .

Это одно из преимуществ пула внутрипроцессных соединений по сравнению с пулом вне процесса, таким как pgbouncer - Npgsql сохраняет информацию о физическом соединении при его передаче, в данном случае это таблица какие операторы подготовлены (имя и SQL).

Answer 2

Я думаю, что это общий вопрос, поэтому я дам общий ответ. Какой аспект применим к конкретной реализации пула соединений, вероятно, будет различным.

Существует несколько режимов пулов соединений:

• Поток сохраняет соединение на время сеанса (пул сеансов):
  В этом случае постоянное состояние, такое как подготовленные операторы, может храниться в течение сеанса, но вы должны очистить состояние, когда сеанс возвращается в пул.

• Поток сохраняет соединение на время транзакции базы данных (пул транзакций):
  В этом случае вам придется очищать состояние после каждой транзакции, поэтому подготовленные операторы не имеют особого смысла.

• Поток сохраняет соединение в течение всего оператора (опрос операторов):
  Это полезно только в очень ограниченных случаях, когда вам не нужны транзакции, охватывающие более одного оператора. Очевидно, что ни одно из состояний, подобных подготовленным заявлениям, не может быть передано.

Это зависит от того, какой пул соединений вы используете. По сути, чем дольше поток сохраняет соединение, тем больше смысла в использовании подготовленных операторов.

Конечно, если вы знаете, что делаете, вы также можете создать подготовленный оператор сразу после установления соединения с базой данных и никогда не освобождать его. Это будет работать, только если все потоки требуют одинаковых подготовленных операторов. С такой установкой легко облажаться.