在我们的数据库中，我们需要动态创建和使用模式。为此，我们想使用动态DbContext，该DbContext在构造时会接受架构名称，并将其用于该上下文中的所有查询。
我们的第一个想法是在搜索路径连接字符串参数中指定架构，从而导致成千上万个不同的连接字符串。我的问题是，这是否是npgsql中连接池策略的预期用例。我读到，为每个连接字符串管理一个单独的连接池，这将导致成千上万个连接池具有一个或两个连接，这似乎很浪费。但是另一方面，在每个用户都有自己的数据库角色的常见用例中。由于在连接字符串中也指定了“角色”，因此该方案还必须处理越来越多的连接字符串。
我们有一个备份策略，其中该架构包含在DbContext的模型中。在这种情况下，我们将不得不管理成千上万种不同的模型，从而导致创建它们的开销或增加用于缓存它们的RAM使用率，但是每个上下文都将使用相同的连接字符串。
答案 0 :(得分：1)
通读this recent issue，其中涉及的内容与此完全相同。
tl; dr是的，连接字符串中的任何差异都会导致连接池不同，因为连接绑定到特定租户且无法共享，这会对性能产生重大影响-在一般情况下，强烈建议只有一个游泳池。
解决此问题的一种方法（如本期所述）是每次切换到新租户时手动设置search_path。