Re: Changing the default configuration (was Re: - Mailing list pgsql-hackers

From Daniel Kalchev
Subject Re: Changing the default configuration (was Re:
Date
Msg-id 200302121152.h1CBqVY05880@dcave.digsys.bg
Whole thread Raw
In response to Re: Changing the default configuration (was Re:  ("scott.marlowe" <scott.marlowe@ihs.com>)
List pgsql-hackers
>>>"scott.marlowe" said:> On 11 Feb 2003, Greg Copeland wrote:> > Besides, I'm not sure that it makes sense to let
otherproduct needs> > dictate the default configurations for this one.  It would be one thing> > if the vast majority
ofpeople only used PostgreSQL with Apache.  I know> > I'm using it in environments in which no way relate to the web.
I'm>> thinking I'm not alone.
 
[...]> You don't have to be using apache to need more than 32 simo connections.  > Heck, how many postgresql databases
doyou figure are in production with that setting still in there?  My guess is not many.> 
 

I would second this. One of my larger PostgreSQL applications uses Apache, 
although it's not typical web server. Apache is restricted to particular 
number of processes and it rarely uses too many backends (but one should 
consider the possible N databases x M apache processes when using persistent 
database connections).

The main connection load on that system however comes from lots of scripts 
that run asynchronously and access the same data (collect, analyze, archive 
data). Even if database access is serialized as much as possible (at the cost 
of performance or wall clock time waste), this load represents sometimes 
hunderts of backends.

My opinion too is that increasing the number of connections will benefit more 
the first-time experience in usability, rather than in performance boost.

The main trouble is, that more connections require not only more semaphores, 
but also more shared memory.

If we are toying with the 'performance' idea, we should definitely increase 
the sort memory default as well :-) ... and this means LOTS of memory for many 
processes.

Is it possible to have some useful connections/memory usage statistics - run 
this code on different installations and collect sufficient data to make 
better choice.

Daniel



pgsql-hackers by date:

Previous
From: Hans-Jürgen Schönig
Date:
Subject: Re: PostgreSQL Tuning Results
Next
From: Jean-Michel POURE
Date:
Subject: PostgreSQL Windows port strategy