On Thu, May 26, 2011 at 5:30 PM, Tom Lane wrote:
>
> OK, maybe word it as "If you're considering raising max_connections much
> above 100, ..." ?
I think it can be even shorter and to the point:
If you're considering raising max_connections consider pooling instead.
--
Sent via pgsql-general m
Thank Graig for the links. You have been very helpful.
When I get time, I will definitely read over the materials to get familar
with Postgres.
Have a wonderful night.
Edison
On Sun, May 29, 2011 at 7:27 PM, Craig Ringer
wrote:
> On 05/30/2011 03:26 AM, Edison So wrote:
>
>> Thanks Graig for y
On 05/30/2011 03:26 AM, Edison So wrote:
Thanks Graig for your comprehensive explanation although I do not
understanding everything you said such as pgbouncer and pg_connect. I
have just started to use Postgres 9.0 with no prior training.
Google is great :-)
http://www.postgresql.org/docs/curr
Thanks Graig for your comprehensive explanation although I do not
understanding everything you said such as pgbouncer and pg_connect. I have
just started to use Postgres 9.0 with no prior training.
I live in Canada and where I live has no instructor-led training on Postgres
9.0 with replication. C
On 29/05/2011 4:39 PM, Craig Ringer wrote:
On 29/05/2011 10:44 AM, Edison So wrote:
Can anyone tell me that if the max_connections is above 100, the server
will use pooling instead?
No. PostgreSQL does not have any built-in connection pooling, that was
the point of the suggestion, to advise pe
On 29/05/2011 10:44 AM, Edison So wrote:
Can anyone tell me that if the max_connections is above 100, the server
will use pooling instead?
No. PostgreSQL does not have any built-in connection pooling, that was
the point of the suggestion, to advise people that they might want to
consider it.
Can anyone tell me that if the max_connections is above 100, the server will
use pooling instead?
For all participants in this particular dsicuss, what is the reasonable
value for max_connections without causing any harm to the Postgres 9.0
server.
I am a nonvice Postgres user so any advice is al
On 05/25/2011 10:58 PM, Craig Ringer wrote:
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
#
# Not
On Fri, May 27, 2011 at 6:22 AM, Craig Ringer
wrote:
> 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
2011/5/27 Tom Lane :
> Craig Ringer writes:
>> On 05/26/2011 09:48 PM, Tom Lane wrote:
>>> Craig Ringer writes:
max_connections = 100 # (change requires restart)
# WARNING: If you're about to increase max_connections above 100, you
# should probably be using a con
Craig Ringer writes:
> On 05/26/2011 09:48 PM, Tom Lane wrote:
>> Craig Ringer 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:
>
On 05/26/2011 09:48 PM, Tom Lane wrote:
Craig Ringer 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_
Craig Ringer 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 impress
On Wed, May 25, 2011 at 10:58 PM, Craig Ringer
wrote:
> There might be a very cheap and simple way to help reduce the number of
> people running into problems because they set massive max_connections values
> that their server cannot cope with instead of using pooling.
>
> In the default postgresq
14 matches
Mail list logo
