2011/5/27 Tom Lane <t...@sss.pgh.pa.us>: > Craig Ringer <cr...@postnewspapers.com.au> writes: >> On 05/26/2011 09:48 PM, Tom Lane wrote: >>> Craig Ringer<cr...@postnewspapers.com.au> writes: >>>> max_connections = 100 # (change requires restart) >>>> # WARNING: If you're about to increase max_connections above 100, you >>>> # should probably be using a connection pool instead. See: >>>> # http://wiki.postgresql.org/max_connections > >>> This gives the impression that performance is great at 100 and falls off >>> a cliff at 101, which is both incorrect and likely to lower peoples' >>> opinion of the software. > >> Fair call; the use of a specific value is misleading. > >>> I'd suggest wording more like "if you're >>> considering raising max_connections into the thousands, you should >>> probably use a connection pool instead". > >> Best performance is often obtained with the number of _active_ >> connections in the 10s to 30s on commonplace hardware. I'd want to use >> "hundreds" - because mailing list posts etc suggest that people start >> running into problems under load at the 400-500 mark, and more >> importantly because it's well worth moving to pooling _way_ before that >> point. > > OK, maybe word it as "If you're considering raising max_connections much > above 100, ..." ?
"Be aware that a too large value can be counter-productive and a connection pooler can be more appropriate." No scale... I am really happy to face more and more servers where 'top' truncate the list of processors... We will have to scale and not make that limitation a feature, imho. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
