Re: [HACKERS] Re: [ADMIN] When postgres will be faster?

Oleg Bartunov wrote:
> I suggest postgres experts  comment this topic. We really need to work
> with different databases using one connection. Postgres is rather good
> scalable DB engine and IMO it's worth to have such feature like
> DB pooling. Once postgres support db pooling it would be possible

The AOLserver webserver/application server already fully supports pooled
database connections to PostgreSQL.

AOLserver is fully multithreaded, and allows a configurable number of
database connections to be persistently pooled.  There can be multiple
pools available, each connecting to a single database.  AOLserver
dynamically manages the pools, with maximum number of pools and pool
persistence timeout configurable.

This allows many thousands of http connections to share a limited number
of database connections, thanks to AOLserver's multithreaded front end.

AOLserver will happily coexist with apache, just by binding to another
port.

The performance increase is on the order of 100 times faster than plain
CGI using the perl Pg module.

AOLserver features tight database integration through a tcl and C API.
The tcl API has specialized database connection commands, http
connection commands, thread creation-mutex-destruction-etc commands, and
many other highly useful (for web scripts) commands that make even tcl a
good web scripting language.  www.aolserver.com, or
aolserver.lcs.mit.edu.

While it might be tempting to lift code out of AOLserver to do pooling,
AOLserver is under the dual APL/GPL license -- such code could be GPL'd,
but not BSD'd.  But, AOLserver's source does give you an example of how
such pooling can be accomplished from a client-side libpq-using program.

The only problem is the issue of libpq's thread-safety or lack thereof
(in practice, the thread-safety issue doesn't show until you hit a high
load).

Ask Vince about AOLserver :-).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11