Attached please find new version of the patch with few fixes. And more results at NUMA system with 144 cores and 3Tb of RAM.
Read-only pgbench (-S):
#Connections\kTPS
Vanilla Postgres
Session pool size 256
1k
1300
1505
10k
633
1519
100k
-
1425
Read-write contention test: access to small number of records with 1% of updates.
#Clients\TPS
Vanilla Postgres
Session pool size 256
100
557232
573319
200
520395
551670
300
511423
533773
400
468562
523091
500
442268
514056
600
401860
526704
700
363912
530317
800
325148
512238
900
301310
512844
1000
278829
554516
So, as you can see, there is no degrade of performance with increased number of connections in case of using session pooling.
TBH, the tests you should be running are comparisons with a similar pool size managed by pgbouncer, not just vanilla unlimited postgres.
Of course a limited pool size will beat thousands of concurrent queries by a large margin. The real question is whether a pthread-based approach beats the pgbouncer approach.
