[erlang-questions] [HEADS UP] Emysql driver
Tue Aug 27 21:16:49 CEST 2013
I love these kind of articles on just how bug fixes and optimizations are
done. Look forward to the next.
On Aug 27, 2013 10:27 AM, "Pablo Polvorin" <>
> Hello, might be interesting to the emysql users, just published a
> first post on some optimizations we have been doing to it
> It is focused on queries returning large result sets, that was our
> original problem. There are more things done but not yet had time
> to complete a writting about it. Note this isn't on oficial emysql
> repo, Jesper did try to include some of the changes, but at that time
> he found some problems (thanks!), solved now on our repo HEAD.
> On 5 July 2013 14:03, Garrett Smith <> wrote:
> > On Fri, Jul 5, 2013 at 10:43 AM, Jesper Louis Andersen
> > <> wrote:
> >> On Fri, Jul 5, 2013 at 4:27 PM, Garrett Smith <> wrote:
> >>> At first glance, it looks like I'd be losing the connect timeout
> >>> enhancements from here:
> >>> https://github.com/gar1t/Emysql
> >> Yes, we are currently missing those changes in the code base. I only
> >> branches which were updated fairly recently on github, and yours were
> >> overlooked for some reason.
> >> I like most of the changes you have in there and most of them definitely
> >> should be part of the full release. I also agree that your functional
> >> to the gen_tcp:recv timeout is something we want to fix. The only slight
> >> worry is that it may be a too big behavioral change for some people. The
> >> other changes are changes I want as well, so i'll probably pull them
> >> you want to prepare a PR yourself.
> > I'll have to look again, but the intent was that default behavior is
> >> I guess the initial reason for having the TCP timeout was to catch slow
> >> queries and get rid of them quickly, rather than waiting around. This
> >> a lot of sense in an environment where you have a large amount of small
> >> queries and are not allowed to wait around. But for larger queries and
> >> procedure calls, this is definitely not what one wants.
> > A default timeout other than infinity strikes me as a very bad idea.
> > There are many reasons, but to your point in particular, a client
> > close during a transaction will trigger a rollback, which can have
> > profoundly negative effects on the system performance -- in many cases
> > much worse then just waiting for the query to finish.
> > Not that this should influence the library feature set, but I tend to
> > deal with problematic long-running queries as an out-of-band problem.
> > E.g. a separate monitor that looks for problem connections and kills
> > them (could be a sys admin in the simplest case).
> >> The whole decoder loop looks weird as well. It should be possible to
> make it
> >> smarter than what is it currently, but this is a future change.
> >> Just drop me a note if you want to push it yourself or I should get to
> >> But it won't be this weekend, so I'll only be able to look at this
> Monday at
> >> the earliest, perhaps late Sunday.
> > I can tackle this -- but it likely won't be within days :)
> > _______________________________________________
> > erlang-questions mailing list
> > http://erlang.org/mailman/listinfo/erlang-questions
> Pablo Polvorin
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions