Re: Connection Pooling, a year later

> > 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.

Yes, that is assuming you are using PHP. If you are using something
else, you connection pooling in there too. All those client interfaces
reimplementing connection pooling seems like a waste to me.

> 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.

No, idle backends take minimal resources.

--
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