SQL99 Complete, ReallyYou can now enjoy  SQL-99 Complete, Really by Peter Gulutzan and Trudy Pelzer aka. “The Definitive Door Stopper” online in our Knowledgebase at http://kb.askmonty.org/v/sql-99-complete-really.

Thanks to our technical writer and system administrator at Monty Program Ab Daniel Bartholomew we now have a complete description of the SQL-99 standard for syntax, data structures, and retrieval processes of SQL databases. As an example-based reference manual it includes all of the CLI functions, information, schema tables, and status codes.

Please make sure to check out our commenting system. You can add your comments for every section of the book.

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.


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.