[pgpool-general: 5488] Re: max_pool parameter question (again!)

Thu May 18 04:40:18 JST 2017

Piotr,
Thank you. Finally I got the point.. so it is really num_init_children that limit the number of concurrent connections that are possible. 
max_pool can only have an impact on the number of postgres connections initiated by pgpool. So in my test case, with num_init_children to 1 and max_pool to 4, I can have only one connection active but if I log in and out with different users I see indeed that more postgres backend connections are created.
In my use case we are going to have a lot of micro-services each connecting to their own schema, so the max_pool can be useful.
Thanks again and regards,
Pierre

On Wednesday, May 17, 2017, 10:45:35 AM GMT+2, Piotr Gbyliczek <P.Gbyliczek at node4.co.uk> wrote: 

| 
| 
| 
|  |

 |   | Piotr Gbyliczek  Solutions Engineer 
|   |
|  ddi. 08454 210444
t. 0845 123 2222
e. P.Gbyliczek at node4.co.uk | Nottingham Office
Node4 Ltd, The POD,
10 Bottle Ln, Nottingham, NG1 2HL |

 | 
|  |

|  |
|   | 
|  |

 |   | 
|  |

 |   | 
|  |

 |   | 
|  |

 |

 |   | 
|  |

 |

 |

| 
|  |

 | 
|  |

 |

 |
|  On Monday, 15 May 2017 18:58:45 BST Pierre Timmermans wrote:
> Hi,
> This question was asked recently (thread 5439) but I don't understand the
> answer (I cannot reply to this thread because I was not yet subscribed). So
> I still cannot understand when the max_pool parameter is taken into
> consideration by pgpool Like in the initial question, I experimented with
> num_init_children=1 and max_pool=2 If I connect with userA, then obviously
> it works. Then, in another window, I connect with userB : but it hangs
> (until I disconnect userA). My understanding of max_pool was that each
> children could cache 2 connections, one for each database user.

You are missing the fact that num_init_children limits your connections from 
client to pgpool. Each child can serve one connection in at the time.

So, you have 2 connection pools to backend servers, but you only allow one 
connection to pgpool, making the second pool utterly pointless. 

Number of pools regulates how often the new connection will benefit from 
already open cached connection to backend, or in other words, how often it 
will suffer from the delay of new backend connections being established. 

For example, if you have an user connecting to 3 databases, then you have 3 
distinctive user/database pairs. It would be best to set max_pool to 3. 
Setting it at 2 as above means that there is 33% chance that new connection 
will have to be established to backend servers (and it will be cached as such 
from that moment).

Regards,
Piotr
-- 

Node4 Limited is registered in England No: 04759927 and has its registered office at Millennium Way, Pride Park, Derby, DE24 8HZ
The information contained in this email is confidential and is intended for the exclusive use of the email addressee shown.
If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited.
If you have received this mail in error, please notify our mail manager at abuse at node4.co.uk and delete it from your system.
Opinions expressed in this email are those of the individual not the company, unless specifically indicated to that effect.This email has been scanned by Node4's Email Security System.This email message has been delivered safely and archived online by Mimecast.  |

 _______________________________________________
pgpool-general mailing list
pgpool-general at pgpool.net
http://www.pgpool.net/mailman/listinfo/pgpool-general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 117051709445602945.jpg
Type: image/jpeg
Size: 21110 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 117051709445603145.jpg
Type: image/jpeg
Size: 29301 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 117051709445603345.png
Type: image/png
Size: 16169 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 117051709445603545.png
Type: image/png
Size: 19452 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 117051709445602145.png
Type: image/png
Size: 1316 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 117051709445602345.png
Type: image/png
Size: 16077 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 117051709445602545.png
Type: image/png
Size: 16234 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 117051709445602745.png
Type: image/png
Size: 17392 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20170517/84b6e238/attachment-0011.png>