On 20.04.2018 12:02, Tatsuo Ishii wrote:
>
> I understand your customers like to have unlimited number of
> connections. But my customers do not. (btw, even with normal
> PostgreSQL, some of my customers are happily using over 1k, even 5k
> max_connections).
If you have limited number of client, then you do not need pooling at all.
With the only one exception if clients for some reasons do not want to
keep connections to database server and
prefer to establish connection on demand and disconnect as soon as possible.
But IMHO in most cases it meas bad design of client application, because
establishing connection (even with connection pooler) is quite expensive
operation.
The primary idea and main benefit of built-in connection pooler is to
>> support session semantic with limited number of backends.
> I am confused. If so, why do you want to push statement based or
> transaction based built-in connection pooler?
I want to provide session semantic but do not start dedicated backend
for each session.
Transaction level rescheduling (rather than statement level resheduling)
is used to avoid complexity with storing/restoring transaction context
and maintaining locks.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
