- connection is bound to backend process it were passed to,
- backend process can perform only one transaction simultaneously,
- therefore if backend process performs long transaction, all other connections on same backend process are waiting for.
Even pgbouncer in transaction mode performs better since it could switch incoming connections to different outgoing connections.
There will be no good builtin connection pooler until PostgreSQL adopts some kind of intra-process concurrency - threads or green-threads (preemptive coroutines). And I say, most likely it will never happen due to all extensions written for PostgreSQL.
- connection is bound to backend process it were passed to, - backend process can perform only one transaction simultaneously, - therefore if backend process performs long transaction, all other connections on same backend process are waiting for.
Even pgbouncer in transaction mode performs better since it could switch incoming connections to different outgoing connections.
There will be no good builtin connection pooler until PostgreSQL adopts some kind of intra-process concurrency - threads or green-threads (preemptive coroutines). And I say, most likely it will never happen due to all extensions written for PostgreSQL.