👍 I comment, from the readme: > There are a few libraries in the same area for clojure, namely spec-tools and malli. > In most cases they focus on openapi/swagger rather than json-schema, which sits at a lower level and now is the foundation for openapi (it wasn’t always the case). both libraries have pure JSON Schema too, e.g. spec-tools.json-schema and malli.json-schema namespaces.

my bad! I ll change that

➕ the name!

I'd love to know your thoughts on why this library benchmarks faster than next.jdbc

Well, maybe because of having less abstractions. The Java code of PG2 is pretty dull and straightforward

do you convert straight off the wire into clojure data types?

I read a byte buffer from a socket, then parse it according to the docs. Then there is a state machine that composes the final result from these messages.

There's definitely some overhead producing ResultSet objects and then converting them to hash maps in next.jdbc so I'm not surprised the query side is faster here. Nice work! I guess that's why insert/update is about equal: omitting all that post-processing. I'll try to remember to link to this from the next.jdbc docs as an alternative for PG users to try out.

So I don't forget: https://github.com/seancorfield/next-jdbc/issues/273

I'd be interested in how this approach compares with and/or can be extended to columnar data access patterns like https://arrow.apache.org/adbc/current/driver/postgresql.html. I'm not sure if analytics is a primary use case for PG2 but something similar that's closer to the wire format would be useful for anyone using stuff like tech.ml.dataset for data work in Clojure.

(at first glance it seems like anything more efficient would depend on upstream changes in Postgres itself)

I wonder how much analytical queries would really benefit from removing little bits of overhead like this, it feels like high fruit on the tree to pick. maybe I'm not dealing with the right datasets or queries to really understand that, though

I mean, removing overhead at the edges like this instead of internally

DuckDB's postgres scanner might be close to the state of the art for the performance ceiling of columnar/analytical queries against a Postgres DB without internal changes to Postgres itself. Similar to PG2, it uses a binary transfer format directly. https://duckdb.org/2022/09/30/postgres-scanner.html

DuckDB is so good, this doesn't surprise me