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.

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?

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.

Comment 4 by daniel.r.heath:

Cool - looks like I'm just misreading then.

Comment 5:

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

Labels changed: removed priority-later.

Status changed to Invalid.