When implementing a wire protocol, one occasionally needs to know something about the wires. This blog post is the story of how the placement of a call to flush-output caused a factor-of-20 variation in performance.
Racket’s db library supports parameterized queries where the SQL is given as a string (that is, unprepared):
(query-list c "SELECT field1 FROM table WHERE field2 = ?" 17)
This is handled by an implicit call to prepare, which turns the string into a prepared statement; the prepared statement is then executed with the arguments.
The problem with this approach is that it involves two trips to the server: one to prepare and one to execute. One trip would be better. In this post I discuss two techniques for eliminating extraneous server trips. I’ve recently added one of them to Racket; the other turns out to be problematic.
I just added support for PostgreSQL arrays to the db library. While there are some uses of arrays that are iffy from a database design standpoint, there’s one use that weighs overwhelmingly in their favor: avoiding dynamic generation of SQL IN comparisons.
