On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote: > 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.
FWIW, I think that's not the right course. We should work towards an in-core pooler. There's very few postgres installations that don't need one, and there's a lot of things that are very hard to do without closer integration. Greetings, Andres Freund
