[pgpool-hackers: 266] Re: transaction pooling mode?

[Ahsan Hadi]

Hi Tatsuo,

Having a transaction pooling mode in pgpool certainly sounds like an
interesting idea. So right now as i understand we have session pooling in
pgpool which mean that connection will only return to the pool once client
session is disconnected. Using the transaction based pooling can be helpful
in cases where we have to manage a very high number of concurrent
connections with short life span however the transaction based pooling
needs to be used carefully by the customer application in order to make
sure that it doesn't break any application features.

So in short, I agree that it would be a interesting feature to add to
pgpool. Do we know if they are real users in the field that use this method
of pooling in pgbouncer? Have they reported any issues with this?

Are you considering this as a 3.4 feature?

-- Ahsan



On Mon, May 27, 2013 at 2:18 PM, Tatsuo Ishii <ishii at postgresql.org> wrote:

> Hi,
>
> It seems pgbouncer's "transaction pooling mode" is pretty attractive
> for those who need huge number of connections(like over a thousand) to
> PostgreSQL. It gives an illusion that users can have many connections
> to PostgreSQL while the actual number of connections stays low.
> Transaction pooling mode is different from pgpool's connection pooling
> in that it returns connection to PostgreSQL to the connection pool
> when a transaction ends(either by commit or abort). On the other hand,
> pgpool does not return the connection to pool until the client
> disconnects to pgpool.
>
> I think implementing the transaction pooling mode is not terribly hard
> in pgpool. Pgpool has single connection data structure to
> frontend. Creating a connection structure array for frontend
> connection will make it possible to implement the transaction pooling
> mode.
>
> BTW, pgpool has the on memory query cache, which is not available in
> pgbouncer. If pgpool has both the transaction pooling mode and the
> query cache, it could be a very attractive solution for those who need
> to handle many concurrent connections with short life, mostly read
> only transactions type.
>
> Comments?
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
> _______________________________________________
> pgpool-hackers mailing list
> pgpool-hackers at pgpool.net
> http://www.pgpool.net/mailman/listinfo/pgpool-hackers
>



-- 
Ahsan Hadi
Snr Director Product Development
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +92-51-8358874
Mobile: +92-333-5162114

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20130530/80cd4294/attachment.html>