2011/5/27 Tom Lane <tgl@sss.pgh.pa.us>:
> Craig Ringer <craig@postnewspapers.com.au> writes:
>> On 05/26/2011 09:48 PM, Tom Lane wrote:
>>> Craig Ringer<craig@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
