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
