Skip to content
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

database/sql: No way to attach prepared statements to pooled connections #4921

Closed
gopherbot opened this issue Feb 26, 2013 · 5 comments
Closed

database/sql: No way to attach prepared statements to pooled connections #4921

gopherbot opened this issue Feb 26, 2013 · 5 comments

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 26, 2013

by daniel.r.heath:

I'm trying to use prepared statements in a reasonably concurrent web app via
database/sql.

Each goroutine handling a request needs to make one of a small set of queries to the
database.

Using prepared statements (prepared before the request starts) would help keep overall
latency down. 
However, preparing a statement takes the database connection out of the pool.

What I'd like to do is register a 'creating connection' handler, and attach prepared
statements to each connection when it gets created. 

This seems like it would be the lowest latency approach since each web request would
have prepared statements ready to go on its connection.
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 26, 2013

Comment 1:

> However, preparing a statement takes the database connection out of the pool.
And puts it back in the pool.  And once that prepared statement needs to run, it prefers
the connection that has it prepared, if it's in the pool and free.  If not, it prepares
another one.
The right amount should soon be prepared, no?

Labels changed: added priority-later, removed priority-triage, go1.1maybe.

Status changed to WaitingForReply.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Feb 27, 2013

Comment 2 by daniel.r.heath:

That makes sense.
Looking at the code, it appears to me as though under highly concurrent loads it will
re-prepare statements many times, because it only remembers the most recently prepared
connection and can't remember that it has prepared the statement on other connections.
Is this correct or am I misreading?
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 27, 2013

Comment 3:

I think (hope) you're misreading.
(*Stmt).Exec calls (*Stmt).connStmt to get a valid conn with that statement prepared. 
connStmt iterates over all of its s.css (list of conn/stmt pairs), and tries to find a
conn that's free.  Only if none are free does it re-prepare a new one.
I intend to do some cleanup in this area for another open bug, but I don't think it's
fundamentally broken right now.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Feb 27, 2013

Comment 4 by daniel.r.heath:

Cool - looks like I'm just misreading then.
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Mar 14, 2013

Comment 5:

Closing, as I think there's nothing to be done here.

Labels changed: removed priority-later.

Status changed to Invalid.

@gopherbot gopherbot added the invalid label Mar 14, 2013
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.