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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026