From: | Rob Nikander <rob(dot)nikander(at)gmail(dot)com> |
---|---|
To: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Async client libraries - not worth it? |
Date: | 2019-06-17 05:34:33 |
Message-ID: | 73BC6656-5B14-4F6A-B0FE-5A1102AEF393@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
[1]: Mentioned here: https://github.com/pgjdbc/pgadba/issues/17
From | Date | Subject | |
---|---|---|---|
Next Message | John Mikel | 2019-06-17 08:58:33 | Re: bug regclass::oid |
Previous Message | Rob Nikander | 2019-06-17 05:09:30 | Re: arrays of composite types, and client drivers like JDBC |