Re: Connection Pooling, a year later

> I don't get the deal with connection pooling.
> 
> Sure, there are some efficiencies in reducing the number of
> back-end postgres processes, but at what I see as a huge
> complication.
> 
> Having experimented with Oracle's connection pooling, and watching
> either it or PHP(Apache) crash because of a bug in the query
> state tracking, I figured I'd buy some more RAM and forget about
> the process memory and call myself lucky.
> 
> If you have a web server and use (in PHP) pg_pConnect, you will
> get a postgresql process for each http process on your web
> servers.
> 
> Beside memory, are there any real costs associated with having
> a good number of idle PostgreSQL processes sitting around?

I think it is the startup cost that most people want to avoid, and our's
is higher than most db's that use threads; at least I think so.

It would just be nice to have it done internally rather than have all
the clients do it, iff it can be done cleanly.

-- Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026