Re: Built-in connection pooling

>> I understand your customers like to have unlimited number of
>> connections. But my customers do not. (btw, even with normal
>> PostgreSQL, some of my customers are happily using over 1k, even 5k
>> max_connections).
>
> If you have limited number of client, then you do not need pooling at
> all.

Still pooler is needed even if the number of connections is low
because connecting to PostgreSQL is very expensive operation as
everybody knows.

BTW, the main reason why Pgpool-II is used is, because it is a pooler,
but query routing: write queies to primary server and read queries to
standbys. This is not possible in bulit-in pooler.

>> I am confused. If so, why do you want to push statement based or
>> transaction based built-in connection pooler?
>
> I want to provide session semantic but do not start dedicated backend
> for each session.
> Transaction level rescheduling (rather than statement level
> resheduling) is used to avoid complexity with storing/restoring
> transaction context and maintaining locks.

Not sure if it's acceptable for community. Probably many developers
want built-in pooler keeps exactly the same semantics as normal
connections.

Tome Lane wrote:
> FWIW, I concur with Heikki's position that we're going to have very high
> standards for the transparency of any in-core pooler. Before trying to
> propose a patch, it'd be a good idea to try to fix the perceived
> shortcomings of some existing external pooler. Only after you can say
> "there's nothing wrong with this that isn't directly connected to its
> not being in-core" does it make sense to try to push the logic into core.

So I would suggest you to start with session level in-core pooler,
which would be much easier than transaction level pooler to make it
transparent.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp