On Thu, Apr 19, 2018, 9:24 AM Konstantin Knizhnik, < k.knizh...@postgrespro.ru> wrote:
> > > On 19.04.2018 07:46, Tsunakawa, Takayuki wrote: > > From: Konstantin Knizhnik [mailto:k.knizh...@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 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 Thanks Dave > -- > Konstantin Knizhnik > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company > > >
