You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In an application with a connection pool, @jfischoff has suggested that it would be better to postpone decoding rows until after the connection is returned to the pool. Can we put together a SQL instance that does so?
If we’re in the middle of a transaction, we need to hold the connection while decoding (assuming the decoded values are used)
If we’re at the end of a transaction, we’d like to return the connection to the pool, decode, then return from runTransaction
I don’t know how to tell whether there are any more statements coming in a do-block; that seems hard with a monad. Maybe we can do something more restrictive, like Applicative?
Maybe an easier approach is lazy decoding. Decoding can fail, and I suspect users still want decoding errors to cause an exception in runTransaction, not later. Maybe we can force any deferred decoding in runTransaction after returning the connection to a pool? That might also let us make field-by-field decisions about decoding intermediate results.
I have not delved into libpq enough to verify that the Result is safe to use while other threads are using the Connection that produced it. Need to do that, or copy all the bytestrings out of the Result before returning the Connection to the Pool - which seems likely to overwhelm any time savings.
The text was updated successfully, but these errors were encountered:
Benchmarking showed that getvalue' is faster than the version that does not copy the bytestring. So copying all the bytestrings and doing further decoding later (eg, JSON parsing) might be a viable approach.
I pushed a branch that (I think) makes decoding lazy. The benchmarks do not show any savings, likely because the variance in running the query swamps the savings. I don't want to make this change without supporting benchmarks, so I'm waiting for a better benchmark design.
I don't want something totally contrived, like a decoder that sleeps. Maybe a sufficiently large JSON payload would show the effect we're interested in?
In an application with a connection pool, @jfischoff has suggested that it would be better to postpone decoding rows until after the connection is returned to the pool. Can we put together a
SQL
instance that does so?If we’re in the middle of a transaction, we need to hold the connection while decoding (assuming the decoded values are used)
If we’re at the end of a transaction, we’d like to return the connection to the pool, decode, then return from
runTransaction
I don’t know how to tell whether there are any more statements coming in a do-block; that seems hard with a monad. Maybe we can do something more restrictive, like Applicative?
Maybe an easier approach is lazy decoding. Decoding can fail, and I suspect users still want decoding errors to cause an exception in runTransaction, not later. Maybe we can force any deferred decoding in runTransaction after returning the connection to a pool? That might also let us make field-by-field decisions about decoding intermediate results.
I have not delved into libpq enough to verify that the Result is safe to use while other threads are using the Connection that produced it. Need to do that, or copy all the bytestrings out of the Result before returning the Connection to the Pool - which seems likely to overwhelm any time savings.
The text was updated successfully, but these errors were encountered: