First I find out the first commit that is in 5.7 that isn’t in 5.6 (using bzr missing) and then look at the authors of all of those commits. Measuring the number of commits is a really poor metric as it does not measure the complexity of the code committed, and if your workflow is to revise a patchset before committing, you get much fewer commits than if you commit 10 times a day.

There are a good number of people who are committing a lot of code to the latest MySQL development tree. (Sorry for the annoying layout of “count. number-of-commits name”)

1. 1022 Magnus Blaudd
2. 723 Jonas Oreland
3. 329 Marko Mäkelä
4. 286 Krunal Bauskar
5. 230 Tor Didriksen
6. 218 John David Duncan
7. 205 Vasil Dimov
8. 197 Sunny Bains
9. 166 Ole John Aske
10. 141 Marc Alff
11. 141 Frazer Clement
12. 140 Jimmy Yang …

There was some suggestion after my previous post (Who works on MariaDB and MySQL?) that I look at MariaDB 10.0 – so I have. My working was very simple, in a current MariaDB 10.0 BZR tree (somewhat beyond 10.0.3), I ran the following command:

bzr log -n0 -rtag:mariadb-10.0.0..|egrep '(author|committer): '| \
  sed -e 's/^\s*//; s/committer: //; s/author: //'| \
  sort -u|grep -iv oracle

MariaDB foundation/MontyProgram/SkySQL:

1. Alexander Barkov
2. Alexey Botchkov
3. Daniel Bartholomew
4. Elena Stepanova
5. Igor Babaev
6. Jani Tolonen
7. knielsen
8. Michael Widenius
9. sanja
10. Sergei Golubchik
11. Sergey Petrunya
12. Sergey Vojtovich
13. timour
14. Vladislav Vaintroub …

I recently got pointed towards https://github.com/shodanium/nanomysql/ which is a tiny (less than 400 lines of C++) MySQL client library which is GPL licensed.

If you need to link into non-GPL compatible code, there is the (slightly larger and full featured) libdrizzle library. But if you want something *tiny* and are okay with GPL, then nanomysql may be something to look at.

Looking at the committers/authors of patches in the bzr tree for MariaDB 5.5.31.

Non Oracle Contributors:

1. Alexander Barkov
2. Alexey Botchkov
3. Elena Stepanova
4. Igor Babaev
5. knielsen
6. Michael Widenius
7. sanja
8. Sergei Golubchik
9. Sergey Petrunya
10. timour
11. Vladislav Vaintroub

Oracle (as they pull Oracle changes):

1. Aditya A
2. Akhila Maddukuri
3. Alexander Nozdrin
4. Anirudh Mangipudi
5. Annamalai Gurusami
6. Astha Pareek
7. Balasubramanian Kandasamy
8. Chaithra Gopalareddy
9. Daniel Fischer
10. Gleb Shchepa
11. Harin Vadodaria
12. Hery Ramilison
13. Igor Solodovnikov
14. Inaam Rana
15. Jon Olav Hauglid
16. kevin.lewis
17. Krunal …

Any introduction to Prepared Statements has to start with SQL Statements.

Every SQL Statement arriving at a database is processed before executing and returning a resultset. The processing is a series of computations including: parsing, compiling, and query optimization.

The parsing, compiling, and query optimization can lead to a lot of wasted CPU if your queries are very similar, like this example from the widely available test database Sakila:

Example Queries:

  SELECT * FROM address WHERE address_id = 12;

  SELECT * FROM address WHERE address_id = 34;

  SELECT * FROM address WHERE address_id = 56;

Example Code, assuming PDO & PHP, to produce those queries:

  $ids = array(12,34,56);

  $sql = “SELECT * FROM address WHERE address_id = “;

…

Whenever I stick my head into the MySQL storage engine API, I’m reminded of a MySQL User Conference from several years ago now.

Specifically, I’m reminded of a slide from an early talk at the MySQL User Conference by Paul McCullagh describing developing PBXT. For “How to write a Storage Engine for MySQL”, it went something like this:

1. Develop basic INSERT (write_row) support – INSERT INTO t1 VALUES (42)
2. Develop full table scan (rnd_init, rnd_next, rnd_end)  - SELECT * from t1
3. If you’re sane, stop here.

A lot of people stop at step 3. It’s a really good place to stop too. It avoids most of the tricky parts that are unexpected, undocumented and unlogical (yes, I’m inventing words here).

There’s a big difference in how plugins are treated in MySQL and how they are treated in Drizzle. The MySQL way has been to create a C API in front of the C++-like (I call it C- as it manages to take the worst of both worlds) internal “API”. The Drizzle way is to have plugins be first class citizens and use exactly the same API as if they were inside the server.

This means that MySQL attempts to maintain API stability. This isn’t something worth trying for. Any plugin that isn’t trivial quickly surpasses what is exposed via the C API and has to work around it, or, it’s a storage engine and instead you have this horrible mash of C and C++. The byproduct of this is that no core server features are being re-implemented as plugins. This means the API is being developed in a vacuum devoid of usefulness. At least, this was the case… The authentication plugin API seems to be an exception, and it’s …

I had reason to look into the extended secondary index code in MariaDB and MySQL recently, and there was one bit that I really didn’t like.

MariaDB:

share->set_use_ext_keys_flag(legacy_db_type == DB_TYPE_INNODB);

MySQL:

use_extended_sk= (legacy_db_type == DB_TYPE_INNODB);

In case you were wondering what “legacy_db_type” actually does, let me tell you: it’s not legacy at all, it’s kind of key to how the whole “metadata” system in MySQL works. For example, to drop a table, this magic number is used to work out what storage engine to call to drop the table.

Now, these code snippets basically kiss goodbye to the idea of a “pluggable storage engine” architecture. If you’re not InnoDB, you don’t get to have certain features. This isn’t exactly MySQL or MariaDB encouraging an open storage engine ecosystem (quite the opposite really).

…

The Example storage engine is meant to serve mainly as a code example of the stub of a storage engine for example purposes only (or so the code comment at the start of ha_example.cc reads). In reality however, it’s not very useful. It likely was back in 2004 when it could be used as a starting point for starting some simple new engines (my guess would be that more than a few of the simpler engines started from ha_example.cc).

The sad reality is the complexity of the non-obviousness of the bits o the storage engine API you actually care about are documented in ha_ndbcluster.cc, ha_myisam.cc and ha_innodb.cc. If you’re doing something that isn’t already done by one of those three engines: good luck.

Whenever I looked at ha_example.cc I always wished there was something more behind it… basically hoping that InnoDB would get a better and cleaner API with the server and would use that rather than the layering violations it has to …

I wonder how much longer the ARCHIVE storage engine is going to ship with MySQL…. I think I’m the last person to actually fix a bug in it, and that was, well, a good number of years ago now. It was created to solve a simple problem: write once read hardly ever. Useful for logs and the like. A zlib stream of rows in a file.

You can actually easily beat ARCHIVE for INSERT speed with a non-indexed MyISAM table, and with things like TokuDB around you can probably get pretty close to compression while at the same time having these things known as “indexes”.

ARCHIVE for a long time held this niche though and was widely and quietly used (and likely still is). It has the great benefit of being fairly lightweight – it’s only about 2500 lines of code (1130 if you exclude azio.c, the slightly modified gzio.c from zlib).

It also use the table discovery mechanism that NDB uses. If you remove the FRM file for an ARCHIVE …