[Pgpool-general] query regarding connection pooling

[Sandeep Thakkar]

That means, even if the free connection is available in the pool, pgpool starts 
a new connection. I think, in terms of connection pooling, pgbouncer looks 
better than pgpool. Because, pgbouncer will always first check in the pool for 
the connection and if found, will reuse it.


Thanks.




________________________________
From: Tatsuo Ishii <ishii at sraoss.co.jp>
To: sandeeptt at yahoo.com
Cc: pgpool-general at pgfoundry.org
Sent: Tue, January 11, 2011 2:59:49 PM
Subject: Re: [Pgpool-general] query regarding connection pooling

> Hi,
> 
> I'm using "pgpool II 3.0.1" against PPAS8.4 and testing the connection pooling 

> feature.
> 
> Here is my settings in pgpool.conf related to this feature:
> num_init_children = 3
> max_pool = 1
> child_life_time = 0
> child_max_connections = 0
> client_idle_limit = 0
> 
> Here is what I did:
> 1. edb-psql -U enterprisedb testdb -p 9999
> 
> On the prompt, using "show pool_pools" command, I saw that the only one 
> connection was established and pool_counter value was "1" and pool_connected 
>was 
>
> also "1". This is expected.
> 
> 2. On another terminal, I executed the same command (same dbname and user) and 
>I 
>
> saw the second connection was established and the values of pool_counter and 
> pool_connected were "1" and this is also expected.
> 
> 3. I disconnected the second session (client) and I executed "show pool_pools" 

> command on the first client prompt, and found that the value of pool_connected 

> was now "0" and pool_counter is "1". This is expected.
> 
> 4. Now, I again start a new client using the same dbname and username, and 
> executed "show pgpool_pools". It shows that a third connection is established. 
>I 
>
> thought, it will not use the third connection and would rather reuse the 
> existing connection, which was available after Step3.
> 
> Am I wrong here? Please help.

This is an expected behavior. When new connectin request arrives, all
idle pgpool children issues accpet(2). Kernel dispatches the
connection request to one of them. The kernel does not care if the
child already has the connection pool for user/db combo. In your
example 4, the kernel just dispatches the request to the child which
unfortunately does not have the connection pool.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pgfoundry.org/pipermail/pgpool-general/attachments/20110111/dd2cd04d/attachment-0001.html>