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