> 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