> The problem with prepared statements is that any given log entry might touch
> different columns in the table. So for a table with 8 columns there are 255
> different possible prepared statements to keep around. In reality, an
> application might show a certain pattern of 4-10 different updates per table,
> but keeping a cache and detecting which statement to use when isn't as easy
> to implement as it is to say "use prepared statements".
I have c++ library for it. Application just needs to send sql stamements and
data separated i.e. ["UPDATE t1 SET x=$1 where y=$2", (x1,y1)] to it and library
turns it into prepared statements and executes it. Its about 15k long (code +
testsuite) - nothing to write home about, just crc32 hash SQL statement, if we
dont have it, prepare it and put on queue ...  Keeping around about 100
prepared statements cached seems to be enough, it misses only rare queries.