-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepared statement gains #1805
Comments
If you're using Postgres JDBC (pgjdbc) driver, it already transparently created server-side prepared statement to cache commonly executed statements (This is scoped per DB connection so if you're using a connection pool it should just work). Keen to see some benchmarks though if anyone wants to compare plain doobie vs reusing the same PreparedStatement object. (The linked docs do say that reusing the PreparedStatment object is more efficient, but I'm not sure by how much) |
Hello,
going into database logs I was surprised to see that all queries are run as
unnamed
prepared statements.E.g for a postgres database with a table:
and a statement:
I can see in logs:
I tried to educate myself on
unnamed
prepared statements, but didn't find any useful information apart from that it's only support on the wire protocol. Can you tell me what gains does it provide? Can a database still remove planning a query part event though at a first glance it's not possible to distinguish oneunnamed
prepared statement from the other?The text was updated successfully, but these errors were encountered: