Re: Built-in connection pooling
| От | Claudio Freire |
|---|---|
| Тема | Re: Built-in connection pooling |
| Дата | |
| Msg-id | CAGTBQpZvnUt8j4R1LSdvJcHy17PxNS=FEb3xN_Gg1wM_+VKvZQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Built-in connection pooling (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
| Ответы |
Re: Built-in connection pooling
|
| Список | pgsql-hackers |
On Thu, Jan 18, 2018 at 11:48 AM, Konstantin Knizhnik <k.knizhnik@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.
В списке pgsql-hackers по дате отправления: