On 19.04.2018 17:27, Dave Cramer wrote:


On Thu, Apr 19, 2018, 9:24 AM Konstantin Knizhnik, <k.knizh...@postgrespro.ru <mailto:k.knizh...@postgrespro.ru>> wrote:



    On 19.04.2018 07:46, Tsunakawa, Takayuki wrote:
    > From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru
    <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

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

Reply via email to