On 18/04/18 06:10, Konstantin Knizhnik wrote:
> But there are still use cases which can not be covered y external
> connection pooler.
Can you name some? I understand that the existing external connection
poolers all have their limitations. But are there some fundamental
issues that can *only* be addressed by a built-in implementation?
For the record, I think an internal connection pool might be a good
idea. It would presumably be simpler to set up than an external one, for
example. But it depends a lot on the implementation. If we had an
internal connection pool, I would expect it to be very transparent to
the user, be simple to set up, and not have annoying limitations with
prepared statements, temporary tables, etc. that the existing external
ones have.
However, I suspect that dealing with *all* of the issues is going to be
hard and tedious. And if there are any significant gaps, things that
don't work correctly with the pooler, the patch will almost certainly be
rejected.
I'd recommend that you put your effort in improving the existing
external connection poolers. Which one is closest to suit your needs?
What's missing?
There are probably things we could do in the server, to help external
connection poolers. For example, some kind of a proxy authentication,
where the connection pooler could ask the backend to do authentication
on its behalf, so that you wouldn't need to re-implement the server-side
authentication code in the external pooler. Things like that.
- Heikki