On 19.04.2018 17:27, Dave Cramer wrote:
On Thu, Apr 19, 2018, 9:24 AM Konstantin Knizhnik, <[email protected] <mailto:[email protected]>> wrote:On 19.04.2018 07:46, Tsunakawa, Takayuki wrote: > From: Konstantin Knizhnik [mailto:[email protected] <mailto:[email protected]>] > 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 driverWe 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
