> 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.
Pgpool-II already does this. If number of concurrent clients exceeds
max_connections, max_connections+1 client have to wait until other
client disconnect the session. So "restricting number of launched
backends" is an indenpendet function from whether "session based"
connection poolers" is used or not.
> 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.
Not neccessarily. i.e. Session based poolers allow to use temporary
tables, prepared statements and keep GUCs and other session state,
while non session based poolers does not allow to use them.
So choosing "session based poolers" or "non session based poolers" is
a trade off. i.e. let user choose one of them.
If you are willing to merge your connection pooler into core, I would
suggest you'd better to implement those pool modes.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp