Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 12:34 AM, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>
>> On Apr 24, 2018, at 06:52, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> Why does it have to be completely transparent?
>
> The main reason to move it into core is to avoid the limitations that a non-core pooler has.

The limitations headaches that I suffer with pgbouncer project (which
I love and use often) are mainly administrative and performance
related, not lack of session based server features. Applications that
operate over a very large amount of virtual connections or engage a
very high level of small transaction traffic are going to avoid
session based features for a lot of other reasons anyways, at least in
my experience. Probably the most useful feature I miss is async
notifications, so much so that at one point we hacked pgbouncer to
support them. Point being, full transparency is nice, but there are
workarounds for most of the major issues and there are a lot of side
channel benefits to making your applications 'stateless' (defined as
state in application or database but not in between).

Absent any other consideration, OP has proven to me that there is
massive potential performance gains possible from moving the pooling
mechanism into the database core process, and I'm already very excited
about not having an extra server process to monitor and worry about.
Tracking session state out of process seems pretty complicated and
would probably add add complexity or overhead to multiple internal
systems. If we get that tor free I'd be all for it but reading
Robert's email I'm skeptical there are easy wins here. So +1 for
further R&D and -1 for holding things up based on full
transparency...no harm in shooting for that, but let's look at things
from a cost/benefit perspective (IMO).

merlin