Re: Pooling in Core WAS: Need help in performance tuning.

Craig Ringer  wrote:
 
> So rather than asking "should core have a connection pool" perhaps
> what's needed is to ask "what can an in-core pool do that an
> external pool cannot do?"
 
(1)  It can prevent the most pessimal performance problems resulting
from lack of an external connection pool (or a badly configured one)
by setting a single GUC.  Configuration tools could suggest a good
value during initial setup.
 
(2)  It can be used without installing and configuring a more
sophisticated and complex product.
 
(3)  It might reduce latency because it avoids having to receive,
parse, and resend data in both directions -- eliminating one "hop". 
I know the performance benefit would usually accrue to the external
connection pooler, but there might be some circumstances where a
built-in pool could win.
 
(4)  It's one more checkbox which can be ticked off on some RFPs.
 
That said, I fully agree that if we can include good documentation
on the external poolers and we can get packagers to include poolers
in their distribution, that gets us a much bigger benefit.  A
built-in solution would only be worthwhile if it was simple enough
and lightweight enough not to be a burden on execution time or
maintenance.  Maybe that's too big an if.
 
-Kevin