What <@U0BGSQ7E0> shared in <#C0CG7E0A1|relational...

# server

[orangy]

What @andrewoma shared in #relational-sql (https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing) pretty much agrees with what I was trying to tell in #ktor.

For example, systems with a mix of long running transactions and very short transactions are generally the most difficult to tune with any connection pool. In those cases, creating two pool instances can work well (eg. one for long-running jobs, another for “realtime” queries).

The problem here is that often you cannot really know upfront if the transaction will be long running or not. It can depend on specific data being requested, query parameters, etc. Without the help from the application developer I don’t think framework can have a chance to automatically balance it.