Hello, I'm having some weird performance issues with hugsql and was wondering if it's something that's already been identified
I have a query that's pretty fast ( about 200ms ) and returns a few 1000s rows ( 3-5 mo of data )
If i make the request using jdbc/query it takes about 200 ms as expected but using Hugsql, it takes about 5 seconds which seems like a way to high overhead
I'm at a loss on how to understand more about this issue, if anyone could provide any tips it would be greatly appreciated, thanks !
Both query are using the exact same Hikari connection pool
The easiest way to debug will be to log queries and their timings on the database level. Is it a local db or remote?
The queries themselves are quite fast, the db doesn't show anything surprising
We managed to pinpoint the problem a bit more, we are overriding hugsql-command-fn for most command / result types with another step that mainly transform db keys to kebab-case
This seems to prevent caching in some way
It's possible to pass jdbc result-set builder that will process the result, let me find an example
(hugsql/set-adapter!
(next-adapter/hugsql-adapter-next-jdbc
{:builder-fn result-set/as-unqualified-lower-maps}))
this code snippet sets the default builder-fn for next.jdbc. You can always pass your custom builder
as follows:
(deftype MyBuilder [^ResultSet rs]
(->row [this]
...)
(column-count [this]
...)
(with-column [this row i]
...)
(with-column-value [this row col v]
...)
(row! [this row]
...)
(->rs [this]
(transient []))
(with-row [this mrs row]
(conj! mrs row))
(rs! [this mrs]
(persistent! mrs))) It looks like you're trying to hack something whereas there is a legal way
Thanks a lot for all that detailed explanations, I'm going to try to implement it this way
Definitely seems like a hack, I'm just trying to understand code that was written a few years ago and seems like we have a bit to fix
Currently we are using hugsql-adapter-clojure-java-jdbc and not hugsql-adapter-next-jdbcbut it probably doesn't change all that much
Right, what I meant here, you can pass defaults for the adapter, and the old clojure.java.jdbc library also has an option to receive cebab-keys, or lower_case fields, and so on