On Thu, Jan 18, 2018 at 11:48 AM, Konstantin Knizhnik < k.knizh...@postgrespro.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.
