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 > > >
