Re: Built-in connection pooling

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, andres(at)anarazel(dot)de
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, sfrost(at)snowman(dot)net, hlinnaka(at)iki(dot)fi, samokhvalov(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Built-in connection pooling
Date: 2018-04-20 07:56:28
Message-ID: 6a404877-7dec-841b-b8a8-77679d8995af@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20.04.2018 01:58, Tatsuo Ishii wrote:
>> I think there's plenty things that don't really make sense solving
>> outside of postgres:
>> - additional added hop / context switches due to external pooler
> This is only applied to external process type pooler (like Pgpool-II).
>
>> - temporary tables
>> - prepared statements
>> - GUCs and other session state
> These are only applied to "non session based" pooler; sharing a
> database connection with multiple client connections. "Session based"
> connection pooler like Pgpool-II does not have the shortcomings.
But them are not solving the main problem: restricting number of
launched backends.
Pgbouncer  also can be used in session pooling mode. But  it makes sense
only if there is limited number of clients which permanently
connect/disconnect to the database.
But I do not think that it is so popular use case. Usually there is very
large number of connected clients which rarely drop connection but only
few of them are active at each moment of time.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2018-04-20 08:07:46 Re: Built-in connection pooling
Previous Message Konstantin Knizhnik 2018-04-20 07:49:31 Re: Built-in connection pooling