Craig Ringer <craig@postnewspapers.com.au> 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
