Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Definitely not a pool as we understand it today, i.e. checking out connections to the requester thread so that it can be used exclusively. I'm imagining that a ractor-friendly db pool would work way differently, i.e. "relaying" the SQL to a "proxy" connection, and from there to a fixed (or not?) pool of ractor workers, each holding its own connection exclusively. I'm over-simplifying perhaps (i.e. transactions would have to be "sticky", so you'd have to make sure you're communicating with the right worker), but bottom line, I agree with the necessary "heavy refactoring" for most of the popular db pools (I'd imagine it'd be simpler in sequel, which already has many different implementations), but I'd be hopeful the result wouldn't be less usable (some more "low-level" APIs would probably have to change though).