Bruce Momjian wrote:
>
> > 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.
You can usually avoid most (all?) of the startup cost by using persistent
connections with PHP.
My concern is, and do you know, besides the memory used by idle postgres
processes, are there any performance reasons why connection pooling a fewer
number of processes, would perform better than a larger number of idle
persistent processes?
Unless it does, I would say that connection pooling is pointless.