On 8/16/2016 12:33 PM, Kristjan Siimson wrote:
Ah, yes. I should of have clarified that I'm trying to build queries,
but I don't want them to be executed. I guess, alternatively, I could
solve it by creating a blackhole database and viewing the executed
queries from the general log. If Im going with that approach, then
this will help me to go in the right direction. Thanks for answering! :-)
Do you mean "prepared" queries? Or something else?
Prepared queries are almost the same as parameterized:
(define stmt (prepare dbc "INSERT INTO x VALUES( ?, ? )" ))
(bind-prepared-statement stmt param-list )
(query-exec dbc stmt )
(bind-prepared-statement stmt another-param-list )
(query-exec dbc stmt )
A prepared query is compiled once and the code is cached on the server
for reuse until the connection is closed or the query is explicitly
dropped. The downside to this is that the prepared query uses a
generic execution plan ... its parameters are not known at compile time
so the query can't be optimized based on particular parameter values
(which affects usage of auxiliary indexes). Also be aware that prepared
queries are tied to specific connections, so connection sharing/pooling
may be problematic. There also are server side limits on the number of
prepared queries allowed - both per connection and globally.
Normal queries are compiled, executed and quickly discarded. In reality
the code is cached for a short time in case the *exact* same query
(including parameter values) is submitted again. The same query string
paired with different parameters will be compiled as a new query.
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
