New Year is coming! And it brings us a new MySQL User Conference! As always, me and my colleagues will be attending — we have great talks to offer:

  • Monty is giving a keynote State of MariaDB. Just like the last year, Monty will tell you how we are doing, what we have spent the last year on, what we are working on now.
  • Colin presents A Beginner’s Guide to MariaDB talk. If you have heard of MariaDB, but don’t quite know what it is and why you should care — go and attend his talk.
  • Sergei (that’s me) together with Andrew Hutchings will give a tutorial Mastering the MySQL Plugin Development. An interactive and updated version of the book that was recently published. Unlike the book, we will use MySQL 5.5 as a base, not 5.1. Most of the material will equally apply to MariaDB and Percona Server — they are all compatible on the Plugin API level.

See you at the conference! It’s going to be a great one!

P.S. Hopefully, Eyjafjallajökull will be quiet this time.

A couple of weeks ago I mentioned in a post that Monty Program was working on a trademark policy for MariaDB, and we hoped to have something available for community review in early 2011.

Well, that draft is ready now. The draft is available in the MariaDB knowledgebase, and we are soliciting public feedback through January 2. During the first week of January any approved edits will be made to make a final version, and that final policy mirrored on mariadb.org and montyprogram.com.

Hopefully the intent of allowing the unhindered development of cool stuff related to MariaDB while protecting the value of the primary brand itself is made clear. Let us know what you think in comments to the KB entry. If you suggest edits, please be sure your reasoning is expressed plainly. Of course, glaring oversights or errors should be brought to our attention regardless of the open commenting deadline. But please make a little time in the next 2 weeks to give us some input.

Thanks!

In our upcoming MariaDB 5.3 release Monty optimized the internal string append code for performance. I tested his patch with a plain MariaDB 5.2 vs. a patched MariaDB 5.2 with sql-bench, which showed an overall performance gain around 3%.

The details of the patch Monty describes like this

Patch to optimize string append:

While examining a trace output from a mysql-test-run case, I noticed a
lot of reallocation calls.  This was strange as MariaDB/MySQL was
designed to do so few malloc/realloc as possible.  The system uses was
to first calculate how big buffer you would need and then allocate a
buffer big enough for most usage. Then there was some safety calls to
extend the buffer if needed.

What had happened in the MySQL code over time was that new coders was
using a buffer that was not preallocated and it was filled with a lot
of append calls(), each which caused a new realloc().

I fixed a couple of the worst cases to prealloc the buffer properly,
and for the other cases I made a general fix by making the
reallocation addaptive:

The essence was to replace the realloc() call with the following function:

In MySQL 5.3, this gave a speedup for some test cases (in debug mode)
with 25 %.  For an optimized version of MySQL we got a general
performance boost of 3 %.  The difference comes from the fact that
we do a lot of extra checks for the malloc() call in a debug build and
fewer malloc() calls gives a notable speed improvement.

The full patch can be seen by doing this in the MariaDB 5.3 tree:
bzr log  -p -r monty@askmonty.org-20101108114354-jl61qx8e36gvbzm7

Here are the detailed results of the sql-bench runs. I ran sql-bench with MariaDB 5.2.2 with default settings and used MyISAM as storage engine.

Column 1 is in seconds. All other columns are presented relative
to this. 1.00 is the same, bigger numbers indicates slower.

1) MariaDB 5.2.2.
2) MariaDB 5.2.2 patched with Monty’s string append optimization.
3) MariaDB 5.2.2 patched with Monty’s string append optimization.
4) MariaDB 5.2.2 patched with Monty’s string append optimization.

The number in () after each tests shows how many SQL commands the particular
test did.  As one test may have many different parameters this gives only
a rough picture of what was done.

I ran the test on a quite fast machine and therefore you can ignore the results with run times around 0 – 3 seconds. I am adjusting the tests to run at least for 5 seconds to have more reliable results.

As machine I used our new benchmark system “pitbull”, which I also used for benchmarking the MyISAM segmented key cache performance.