Re: Built-in connection pooling

On 25.04.2018 17:00, Merlin Moncure wrote:
> On Wed, Apr 25, 2018 at 12:34 AM, Christophe Pettus <xof@thebuild.com> wrote:
>>> On Apr 24, 2018, at 06:52, Merlin Moncure <mmoncure@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
I did more research and find several other think which will not work 
with current built-in connection pooling implementation.
One you have mentioned: notification mechanism. Another one is advisory 
locks. Right now I have now idea how to support them for pooled sessions.
But I will think about it. But IMHO neither notifications, neither 
advisory locks are so widely used, comparing with temporary tables and 
prepared statements...

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company