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
