On Wed, Apr 25, 2018 at 12:34 AM, Christophe Pettus <x...@thebuild.com> wrote: > >> On Apr 24, 2018, at 06:52, Merlin Moncure <mmonc...@gmail.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
