Great, this latest patch applies cleanly to master. installcheck world still passes.
> "connections_proxies" is used mostly to toggle connection pooling.
> Using more than 1 proxy is be needed only for huge workloads (hundreds
> connections).
My testing showed using only one proxy performing very poorly vs not using the pooler, even at 300 connections, with -3% TPS. At lower numbers of connections it was much worse than other configurations I tried. I just shared my full pgbench results [1], the "No Pool" and "# Proxies 2" data is what I used to generate the charts I previously shared. The 1 proxy and 10 proxy data I had referred to but hadn't shared the results, sorry about that.
> And "session_pool_size" is core parameter which determine efficiency of
> pooling.
> The main trouble with it now, is that it is per database/user
> combination. Each such combination will have its own connection pool.
> Choosing optimal value of pooler backends is non-trivial task. It
> certainly depends on number of available CPU cores.
> But if backends and mostly disk-bounded, then optimal number of pooler
> worker can be large than number of cores.
I will do more testing around this variable next. It seems that increasing session_pool_size for connection_proxies = 1 might help and leaving it at its default was my problem.
> PgPRO EE version of connection pooler has "idle_pool_worker_timeout"
> parameter which allows to terminate idle workers.
