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.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
