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
