Re: PostgreSQL pre-fork speedup

> Or, you run several seperate Apache webservers. The ones that serve static
> content or don't need database connections don't run with the ones that do.
> And just like each idle Apache process uses memory and other resources,
> each idle PostgreSQL connection does to. So managing the number of Apache

Considered that, but it doesn't help much. The duty cycle of any given
page is about 20% database, 80% webserver work. So at any given time 80%
of the connections to the database will be idle in a best case scenario.

If Apache did decent connection pooling or PostgreSQL gave us a hand
then a given webserver would need 1/4 of the connections which could be
internally shared.

Page 1 start
Page 1 DB connect

Page 1 DB disconnect
.
. <IDLE persistent connection as work happens>
.
Page 1 transmit results

If we could really disconnect from the database and not suffer high
re-connection overhead OR have Apache recognize the connection is unused
and allow another Apache backend to use it there would not be a problem.

> It all comes down to management, which Apache does a reasonable job of.

> If you really believe that you are right and I am wrong, then prove it. I'll
> be happy to be shown the error of my thinking (and see an improvement to
> PostgreSQL in the process).

You wouldn't run into a problem like this on a system with good
connection pooling. JBoss comes to mind, once a connection is free it is
available to other threads to use. AOL Server is a webserver which
demonstrates proper connection pooling.

Apache is the problem we're trying to work around. It does everything
per backend, rather than having a common pool for the server. That can
be fixed by improving PostgreSQL or by doing something (I'm not sure
what) with apache.