Is there an existing issue for the same feature request?
[X] I have checked the existing issues.
Is your feature request related to a problem?
If client quickly establish many connections, run a simple query then disconnect, the connection/session overhead is pretty high.
Proxy should auto pool such connections.
Describe the feature you'd like
At proxy, proxy receive connection request, establish connect to matrixone database. If customer disconnects, proxy can keep the connection to matrix one alive, for a short period of time. When next connection comes in, we check if we can reuse an existing connection.
Describe implementation you've considered
Note that we probably want to reuse connect with same user and same authentication method. We should keep all privilege check etc cached/reused as well.
To reuse an existing connection/session, any state of the session must reset -- session variables and prepared statement handles comes to mind.
Number of cached connections, for how long, etc, should be policy driven. Maybe policy should be per account.
Documentation, Adoption, Use Case, Migration Strategy
No response
Additional information
Connection pooling can happen at different unit of work. It can be statement (means different statement can run using different connection), transaction (means different transactions can run using different connections, but all statement in one transaction are executed in one connection), session. We want session level pooling because we can/must preserve the semantics of session.
volgariver6
commented
2 weeks ago
Is there an existing issue for the same feature request?
Is your feature request related to a problem?
Describe the feature you'd like
At proxy, proxy receive connection request, establish connect to matrixone database. If customer disconnects, proxy can keep the connection to matrix one alive, for a short period of time. When next connection comes in, we check if we can reuse an existing connection.
Describe implementation you've considered
Note that we probably want to reuse connect with same user and same authentication method. We should keep all privilege check etc cached/reused as well.
To reuse an existing connection/session, any state of the session must reset -- session variables and prepared statement handles comes to mind.
Number of cached connections, for how long, etc, should be policy driven. Maybe policy should be per account.
Documentation, Adoption, Use Case, Migration Strategy
No response
Additional information
Connection pooling can happen at different unit of work. It can be statement (means different statement can run using different connection), transaction (means different transactions can run using different connections, but all statement in one transaction are executed in one connection), session. We want session level pooling because we can/must preserve the semantics of session.