On Mon, 17 Jun 2019 at 01:34, Rob Nikander <rob.nikan...@gmail.com> wrote:
> Hi, > > I’m writing a new web app, and I’ve been experimenting with some async DB > access libraries [1]. I also see some discussion online about a future Java > standard to replace or supplement JDBC with an async API. > > While I understand the benefits of async in some situations, it seems to > me that these libraries are not going to give much performance benefit, > given the architecture of a PostgreSQL server. (Nothing against PG; > probably most RDBMSs are like this.) > > I wonder if anyone else has looked at this and agrees, or not. ? > > A client library with an async-style API may allow 100,000s of concurrent > “operations”, but since the PG server itself doesn’t handle connections on > that scale (and has no plans to, I assume?), the client library is really > maintaining a queue of operations waiting for a connection pool. Maybe > there is some performance benefit there, but the most important point - to > free up the front end to handle many HTTP connections - can also happen by > combining an operation queue with a synchronous API. > > Rob > > https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=db Seems to be worth it. Now it appears that ADBA is going to die on the vine, R2DBC and vertx seem to be pretty good Dave Cramer da...@postgresintl.com www.postgresintl.com
