Когда устанавливается подключение к PostgreSQL, для каждого клиента запускается отдельный обслуживающий процесс. При большом количестве клиентов этой модели присущи повышенная нагрузка на системные ресурсы и значительное снижение производительности, особенно на многоядерных системах. Это объясняется увеличением конкуренции при обращении множества процессов к ресурсам PostgreSQL. Кроме того, размер многих внутренних структур данных PostgreSQL пропорционален сложности обрабатывающих их алгоритмов и числу активных обслуживающих процессов.

В большинстве инсталляций Postgres Pro для ограничения числа запускаемых обслуживающих процессов применяются внешние средства, например, J2EE, odyssey или pgbouncer, один из наиболее популярных пулов соединений для Postgres Pro. Однако применение внешних пулов соединений подразумевает дополнительные издержки, связанные с их установкой, настройкой и сопровождением. Кроме того, если пул работает в одном потоке, как pgbouncer, вам также придётся запускать несколько экземпляров пула, чтобы он не оказался узким местом в сильно нагруженных системах.

Решить эти проблемы призван встроенный в Postgres Pro Enterprise экспериментальный пул соединений. В отличие от внешних решений он не требует дополнительного обслуживания и не налагает никаких ограничений на клиентов. Клиенты, взаимодействующие с сервером через встроенный пул соединений, могут использовать параметры конфигурации сеансов, подготовленные операторы и временные таблицы так же, как и напрямую.

В следующих разделах описывается архитектура встроенного пула соединений и приводятся инструкции по его настройке.