On 3/13/2017 5:43 PM, Ryan Culpepper wrote:
Racket's db library always prepares a statement before executing it,
even if there are no query parameters. When allowed, instead of
closing the prepared statement immediately after executing it, the
connection stores it in a (Racket-side, per-connection) cache. The
cache key is just the SQL string. If you use the same query string
with different parameters, you'll still get the cached prepared
To extend my previous example:
> (query c "select $1::integer" 1)
** caching statement
> (query c "select $1::integer" 2)
** using cached statement
On the other hand, if the query string is not identical, it misses the
Hmm. Then what is the purpose of having separate (prepare ...)? And
what happens if the unknowing user issues a PREPARE statement for the
query directly to the DBMS?
Then there is the issue that deliberately prepared queries are not
optimized as heavily as normal queries - which is the case in pretty
much every DBMS that exists. Heavyweight queries that require maximum
performance are harmed by preparation.
Moreover, prepared queries are not cached in the normal sense ... they
persist until explicitly dropped, or until the connection is closed.
There are both per connection and global limits on the number of
prepared queries, and bad things can happen if these limits are
exceeded [e.g., I've seen versions of Postgresql freeze and Sybase
crash in such circumstances]. A long running application using pool
connections could get into trouble.
You received this message because you are subscribed to the Google Groups "Racket
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.