Fork me on GitHub
#sql
<
2020-08-11
>
Ben Sless07:08:41

Should I expect to see a performance improvement with hugsql when switching from the default adapter to jdbc.next adapter? didn't see much difference when I tried it in a production environment.

lukasz14:08:23

We didn't notice any directly, but some things are nicer, like extending PG types as compared to clojure.jdbc

seancorfield15:08:49

@ben.sless since HugSQL isn't using plan, the only performance difference you'll see is in "large" result sets that will be constructed quite a bit faster than with c.j.j

seancorfield15:08:06

(that can be quite a substantial difference)

seancorfield15:08:01

Also, if you construct a datasource once from a db-spec, and then use that datasource everywhere, that should also be a bit faster (using a connection pooled datasource would be faster, of course, and that is also true of c.j.j).

Ben Sless11:08:52

Just wanted to update that I deployed next.jdbc today and I see speedups of up to 20% in some places. Thank you 🙂

seancorfield16:08:03

Nice! Thanks for following up on that!

🙏 3
Ben Sless18:08:48

Thank you for all the work you put into it and all the help you provide to the community

Ben Sless15:08:39

I see. Thanks 🙂

synthomat18:08:08

using a datasource does jdbc-next re-connect to the database with each query?

synthomat18:08:15

I’m not using connection pooling

synthomat18:08:38

just wondering why my application reacts so slowly when deployed on a shared hoster. the response time locally is good

seancorfield19:08:22

@synthomat Yes, if you use a db-spec (hash map) or connection URL string, then next.jdbc (and c.j.j) will make a datasource from that and then call .getConnection on it; if you use a datasource, both libraries will call .getConnection on it. You can either use get-connection and with-open (as shown in the docs) to reuse a connection across multiple operations, or you can use a connection pooled datasource (the recommended approach).

seancorfield19:08:04

next.jdbc has built-in support for both HikariCP and c3p0 (and any others that follow the same API pattern as those two -- but those two are the supported and tested ones).

seancorfield19:08:51

On shared hosting, it's entirely possible that standing up a new DB connection is very expensive (it's expensive, in relative terms, even locally but not so much that you really notice).

synthomat19:08:17

It’s actually my own instance running in my isolated process group. But anyway I should use a pooling datasource. Thanks for the answer!