Re: Built-in connection pooling

When I've been thinking about adding a built-in connection pool, my
>> rough plan was mostly "bgworker doing something like pgbouncer" (that
>> is, listening on a separate port and proxying everything to regular
>> backends). Obviously, that has pros and cons, and probably would not
>> work serve the threading use case well.
>>
>
> And we will get the same problem as with pgbouncer: one process will not
> be able to handle all connections...
> Certainly it is possible to start several such scheduling bgworkers... But
> in any case it is more efficient to multiplex session in backend themselves.
>

pgbouncer hold all time client connect. When we implement the listeners,
then all work can be done by worker processes not by listeners.

Regards

Pavel

> But it would have some features that I find valuable - for example, it's
>> trivial to decide which connection requests may or may not be served
>> from a pool (by connection to the main port or pool port).
>>
>> That is not to say the bgworker approach is better than what you're
>> proposing, but I wonder if that would be possible with your approach.
>>
>>
>> regards
>>
>>
> --
> Konstantin Knizhnik
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
>
>