Re: Built-in connection pooling

On 25.10.2018 11:53, Konstantin Knizhnik wrote:
> I continue work on built-in connection pooler.
> I have implemented three strategies for splitting sessions between 
> session pool workers:
> - random
> - round-robin
> - load balancing (choose server with minimal wait queue size)
>
> It is still not fixing the main drawback of the current implementation 
> of built-in pooler: long transaction or query can block all other 
> sessions
> scheduled to this backend. To prevent such situation we have to 
> somehow migrate session to some other (idle) backends.
> Unfortunately session should take with it a lot of "luggage": 
> serialized GUCs, prepared statements and, worst of all, temporary tables.
> If first two in principle can be handled, what to do with temporary 
> table is unclear.
>
> Frankly speaking I think that implementation of temporary tables
> in Postgres has to be rewritten in any case. Them are causing catalog 
> blow, can not be used in parallel queries,...
> May be in case of such rewriting of temporary tables implementation 
> them can be better marries with built-on connection pooler.
> But right now sessions can not be migrated.
>

Updated version of builtin connection pooler fixing  issue with open 
file descriptors limit exhaustion.

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