Re: Built-in connection pooling

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