[erlang-questions] [HEADS UP] Emysql driver
Tue Aug 27 21:18:40 CEST 2013
Thoroughly enjoyed. Looking forward to the next.
On Tue, Aug 27, 2013 at 9:16 PM, OvermindDL1 <> wrote:
> 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
>> >> 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
>> >> worry is that it may be a too big behavioral change for some people.
>> >> 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
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions