On 18.04.2018 16:41, Heikki Linnakangas wrote:
> On 18/04/18 07:52, Konstantin Knizhnik wrote:
>>
>>
>> On 18.04.2018 13:36, Heikki Linnakangas wrote:
>>> On 18/04/18 06:10, Konstantin Knizhnik wrote:
>>>> But there are still use cases which can not be covered y external
>>>> connection pooler.
>>>
>>> Can you name some? I understand that the existing external connection
>>> poolers all have their limitations. But are there some fundamental
>>> issues that can *only* be addressed by a built-in implementation?
>>
>> Well, may be I missed something, but i do not know how to efficiently
>> support
>> 1. Temporary tables
>> 2. Prepared statements
>> 3. Sessoin GUCs
>> with any external connection pooler (with pooling level other than
>> session).
>
> Me neither. What makes it easier to do these things in an internal
> connection pooler? What could the backend do differently, to make
> these easier to implement in an external pooler?
All this things are addressed now in my builtin connection pool
implementation:
1. Temporary tables are maintained by creation of private temporary
namespace for each session
2. Prepared statements are supported by adding unique session prefix to
each prepared statement name (so there is single prepare statement cache
in backend, but each session has its own prepared statements)
3. Each session maintains list of updated GUCs and them are
saved/restored on reschedule.
It was not so difficult to implement all this stuff (the main troubles I
had with GUCs), but looks like none of them are possible fort external
connection pooler.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company