Educated snark is much better than uneducated snark. Why don't you take the time to understand why TokuDB benefits from jemalloc before suggesting they fix their code. mysqld has always been faster for me with tcmalloc & jemalloc versus glibc malloc. I don't recall much support from everyone at official MySQL when I was reporting those problem. Why didn't you fix mysqld back then so I didn't have to waste time on that? http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html http://mysqlha.blogspot.com/2008/12/make-mysql-faster-in-one-hour_14.html http://mysqlha.blogspot.com/2009/01/innodb-is-faster-tcmalloc-is-nice.html On Thu, Apr 25, 2013 at 9:47 AM, Vladislav Vaintroub <wlad@montyprogram.com>wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Kristian Nielsen Sent: Donnerstag, 25. April 2013 18:30 To: Daniel Bartholomew Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
It is said that tokutek "requires" jemalloc - maybe it would be better to
fix
tokutek to work with standard libraries?
I wanted to say the same. I do not understand quite how it is possible to rely on malloc replacement library - it is a replacement, it is typically handled at runtime (using LD_PRELOAD environment variable). Perhaps someone familiar with the subject can enlighten us on it.
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com