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
