-
Notifications
You must be signed in to change notification settings - Fork 18k
database/sql: proper prepared statement support in transactions #15606
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
Comments
I was working on making this work here, but I never finished; and I never will so if you're interested, you could try picking it up. |
FWIW I just ran into this in production, and I only figured it out by logging raw packets. This is a huge gotcha. |
@quentinmit please drop by https://groups.google.com/forum/#!forum/golang-sql if you get a chance. I hope to tackle it soon(tm). |
CL https://golang.org/cl/35266 mentions this issue. |
The MySQL protocol requires 1-3 synchronous round-trips for every INSERT statement; to reduce the overhead, we now batch up 900 label INSERT statments at a time. This makes a massive difference; TestQuery previously ran in 108s; with this change, it now runs in 5s. We were also affected by golang/go#15606; since we now generate a new INSERT statement for every record, we are sidestepping that issue. Change-Id: Id7a56c18c0978470542135894a2f2bcf6f7c9dd1 Reviewed-on: https://go-review.googlesource.com/35266 Reviewed-by: Russ Cox <rsc@golang.org>
Mailed, https://go-review.googlesource.com/#/c/35476/ |
CL https://golang.org/cl/35476 mentions this issue. |
A very common use case is to create a bunch of prepared statements in a connection manager concern, when a new connection is needed and created (say, when a component requests a connection from a connection pool and there is not an idle one at the moment), associate the user context with a transaction on the returned connection (say when a web service begins to execute an http service request with a connection obtained from a connection pool), and then execute the prepared statements in it.
It seems, however, that Go database/sql requires the recompilation of every prepared statement each time it executes:
This is not fine, I think - it's worse than useless. In particular, it's strictly less performant (and /quietly/ so!) than not using statements where there are transactions in use.
So, we have a situation, it seems, where there is no de facto prepared statement support. Is this really the case? What needs to be done to implement support?
It appears as though Stmt /already/ knows how to do the right thing wrt transactions:
Can we just create
func (tx *Tx) ExecStmt(s *Stmt, args ...interface{}) ...
and the like, which shallow-clone the Stmt (ie. reuse the same driver statement object), and associate a transaction with the new copy, before calling its Exec()?
The text was updated successfully, but these errors were encountered: