Re: Built-in connection pooling

On 25.04.2018 08:34, Christophe Pettus wrote:
>> On Apr 24, 2018, at 06:52, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> Why does it have to be completely transparent?
> Well, we have non-transparent connection pooling now, in the form of pgbouncer, and the huge fleet of existing application-stack poolers. The main reason to move it into core is to avoid the limitations that a non-core pooler has.

What do we mean by "completely transparent"? If complete transparency
means that polled sessions behaves exactly the same as normal session in
dedicated backend then it will be really difficult to achieve, taken in
account all error handling nuances, issue with srandom, and may be some
other contexts with session lifetime...

But I start development of built-in connection poller because of our
customer's requests.
For example 1C clients never drop connections and 1C application is
widely using temporary tables.
So them can not use pgbouncer  and number of clients can be very larger
(thousands).
Built-in connection pooling will satisfy their needs. And the fact that
random() in polled connection will return different values is absolutely
unimportant for them.

So my point of view is the following:
1. Support of temporary tables in pooled sessions is important because
them are widely used in many applications.
2. Support of prepared statements in polled sessions is also useful,
because it allows to increase performance up to two times.
3. Support of GUCs is also required, because there are many things:
locale, date format, timezone which are set by client application using
GUCs.

Other things seems to be less important.
If there are some static variables (not associated with GUCs) with
session (backend) lifetime, then them can be moved to session context.
I just do not know some variables.

>
> --
> -- Christophe Pettus
> xof(at)thebuild(dot)com
>

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