Search Postgresql Archives

Re: Async client libraries - not worth it?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






On Mon, 17 Jun 2019 at 01:34, Rob Nikander <rob.nikander@xxxxxxxxx> 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

davec@xxxxxxxxxxxxxxxx
www.postgresintl.com



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux