You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once NpgsqlDataSource is integrated, we can reimplement multiplexing
This represents multiplexing exactly where it is API-wise: at the database/pool level, not associated to any particular connection instance.
This would make it impossible to accidentally depend on connection state, which isn't supported in multiplexing (e.g. 45270fa)
It would considerably simplify our internal code, since we'll no longer have to deal with bound/unbound connections - connections are always bound. Instead we'd just have a MultiplexingNpgsqlCommand (internal type) which implements the multiplexing logic.
I think we still want multiplexing to be opt-in on the connection string.
Note: if we no longer support multiplexing on NpgsqlConnection (which we ideally shouldn't), then EF Core and other layers must react and use DbDataSource in order to get the perf benefits of multiplexing.
The text was updated successfully, but these errors were encountered:
Once NpgsqlDataSource is integrated, we can reimplement multiplexing
Note: if we no longer support multiplexing on NpgsqlConnection (which we ideally shouldn't), then EF Core and other layers must react and use DbDataSource in order to get the perf benefits of multiplexing.
The text was updated successfully, but these errors were encountered: