I'll have to benchmark withMVar on my system, but (at least on my old
laptop) a safe foreign function call is also on the order of 100ns. As
c_PQescapeStringConn and c_PQescapeByteaConn are currently safe calls,
that would limit the maximum time saved at ~50%.
Perhaps it would make sense to mak
On Mon, Jul 8, 2013 at 9:03 PM, Leon Smith wrote:
> I just fixed a fairly serious performance problem with postgresql-libpq's
> binding to PQescapeStringConn; in was exhibiting a non-linear slowdown
> when more strings are escaped and retained.
>
I'd like to point out a somewhat related bottl
