Re: Built-in connection pooling

On 19.04.2018 17:27, Dave Cramer wrote:
>
>
> On Thu, Apr 19, 2018, 9:24 AM Konstantin Knizhnik,
> <k(dot)knizhnik(at)postgrespro(dot)ru <mailto:k(dot)knizhnik(at)postgrespro(dot)ru>> wrote:
>
>
>
> On 19.04.2018 07:46, Tsunakawa, Takayuki wrote:
> > From: Konstantin Knizhnik [mailto:k(dot)knizhnik(at)postgrespro(dot)ru
> <mailto:k(dot)knizhnik(at)postgrespro(dot)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 Connection Pooling
> (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't you?  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
>
>
>
> It would be useful to test with the JDBC driver
>
> We run into issues with many pool implementations due to our
> opinionated nature

I have tested built-in connection pool with YCSB benchmark which is
implemented in Java and so works through JDBC driver.
Results were published in the following mail in this thread:
https://www.postgresql.org/message-id/7bbbb359-c582-7a08-5772-cb882988c0ae%40postgrespro.ru

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