Re: Changing the default configuration (was Re:

Поиск
Список
Период
Сортировка
От Daniel Kalchev
Тема Re: Changing the default configuration (was Re:
Дата
Msg-id 200302121152.h1CBqVY05880@dcave.digsys.bg
обсуждение исходный текст
Ответ на Re: Changing the default configuration (was Re:  ("scott.marlowe" <scott.marlowe@ihs.com>)
Список 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 по дате отправления:

Предыдущее
От: Hans-Jürgen Schönig
Дата:
Сообщение: Re: PostgreSQL Tuning Results
Следующее
От: Jean-Michel POURE
Дата:
Сообщение: PostgreSQL Windows port strategy