Re: Built-in connection pooling - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Built-in connection pooling
Date
Msg-id 400361c8-06aa-7212-847f-26e5f6254627@postgrespro.ru
Whole thread Raw
In response to Re: Built-in connection pooling  (Christophe Pettus <xof@thebuild.com>)
List pgsql-hackers

On 25.04.2018 08:34, Christophe Pettus wrote:
>> On Apr 24, 2018, at 06:52, Merlin Moncure <mmoncure@gmail.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-stackpoolers.  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@thebuild.com
>

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



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Oddity in tuple routing for foreign partitions
Next
From: Haozhou Wang
Date:
Subject: Re: [PATCH] Add missing type conversion functions for PL/Python