Re: Built-in connection pooling - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Built-in connection pooling
Date
Msg-id 0bbd7c63-eb39-8f9a-985c-07aebbb5f4b1@postgrespro.ru
Whole thread Raw
In response to RE: Built-in connection pooling  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: Built-in connection pooling  (Dave Cramer <davecramer@gmail.com>)
List pgsql-hackers

On 19.04.2018 07:46, Tsunakawa, Takayuki wrote:
> From: Konstantin Knizhnik [mailto:k.knizhnik@postgrespro.ru]
> Oracle, for example, you can create dedicated and non-dedicated backends.
>> I wonder why we do not want to have something similar in Postgres.
> Yes, I want it, too.  In addition to dedicated and shared server processes, Oracle provides Database Resident
ConnectionPooling (DRCP).  I guessed you were inspired by this.
 
>
> https://docs.oracle.com/cd/B28359_01/server.111/b28310/manproc002.htm#ADMIN12348

It seems to be that my connection pooling is more close to DRCP than to 
shared servers.
It is not clear from this article what this 35KB per client connection 
are used for...
It seems to be some thing similar with session context used to 
suspend/resume session.
In my prototype I also maintain some per-session context to keep values 
of session specific GUCs, temporary namespace, ...
Definitely pooled session memory footprint depends on size of catalog, 
prepared statements, updated GUCs,... but 10-100kb seems to be a 
reasonable estimation.


>
> BTW, you are doing various great work -- autoprepare, multithreaded Postgres, built-in connection pooling, etc. etc.,
aren'tyou?  Are you doing all of these alone?
 
Yes, but there is huge distance from prototype till product-ready 
solution. And definitely I need some help here. This is why I have to 
suspend future development of multithreaded version of Postgres (looks 
like it is not considered as some realistic project by community).
But with builtin connection pooling situation is better and I am going 
to tests it with some our clients which are interested in this feature.

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



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Should we add GUCs to allow partition pruning to be disabled?
Next
From: Alvaro Herrera
Date:
Subject: Re: initdb fails to initialize data directory