Re: Built-in connection pooling

On Thu, Jan 18, 2018 at 11:48 AM, Konstantin Knizhnik <
k(dot)knizhnik(at)postgrespro(dot)ru> wrote:

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