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 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
