Parts of the world are already celebrating Christmas Eve and it’s time to relax and spend time with family and friends. Even if you don’t celebrate Christmas this is when there is time for less work. Here are a few words to round off MariaDB’s current state and where it’s heading.

This year culminated in MariaDB 5.3.3, the release candidate of 5.3. This is a significant release that makes years of work available by default in the database server. Earlier releases still required features to be explicitly switched on, but thanks to thorough testing assuring the quality of the new functionality we have now enabled them. It’s still called a release candidate which means it’s ready for general usage, but we want more user feedback before calling it stable. Make yourself familiar with the MariaDB 5.3.3 release notes.

Most of the new features and …

…with a bit of strategic thinking

They come back, every now and then. Subqueries are far from being perfect at MySQL and they can give you some serious headaches.

Skilled MySQL developers know it better. They avoid subqueries as much as they can. It is not that subqueries do not work, it is just that the optimizer sometimes is, well, “not that optimised”.

So you may stay away from subqueries with some good SQL review. But what happens when the subquery is automatically generated by a script or a tool? If you can change the statement, I’m afraid you need to find some serious workarounds that vary case by case.

Here is an example that I found few weeks ago when I visited one of our customers.

Our customer used Magento for its site. Magento used a couple of queries that I will report here as sales and sales_items, …

Three days ago I’ve finally managed to push the code for WL#3985 “Subquery optimization: smart choice between semi-join and materialization” into MySQL 6.0. I missed the clone-off date so it won’t be in the upcoming MySQL 6.0.9 release, the only way to get it before the next 6.0.10 release is from the lp:mysql-server/6.0 bazaar repository.

What’s new in the push

Before WL#3985, 6.0’s subquery optimization had these three deficiencies:

1. For semi-join (see cheatsheet for definition) subqueries, you had to make a choice between having the optimizer use materialization or all other strategies. The default behavior was not to use …

I'm now at MySQL Conference and have just finished my New Subquery Optimizations in MySQL 6.0 talk. If you're eager to get the slides, here is the link to the pdf file and a mirror.

The talk has the same name as this MySQL University session but the slides have been thoroughly re-worked, and also there is new content:

• More detailed explanation of subquery handling in 4.1/5.x
• More reliable/justified benchmark numbers
• Observations about subquery demographics
• An attempt at comparative analysis of how MySQL's …

One of my colleagues made a typo in a query today that led to me discovering this issue — I think it’s a bug, though it may just be how the language is defined. But certainly a subquery that cannot run should not act as if it returns TRUE.

mysql> use test;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed
mysql> create table foo (fid tinyint unsigned not null primary key); create table bar (bid char(1)
not null default ”);
Query OK, 0 rows affected (0.01 sec)

Query OK, 0 rows affected (0.01 sec)

mysql> insert into foo (fid) VALUES (1),(2); insert into bar (bid) VALUES (’1′),(’a');
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

…

The work on subquery optimizations goes on, and we're already curious how the assortment of new 6.0 subquery optimizations compares to what is found in other DBMSes. MySQL's new strategies are not DBMS theory breakthroughs, similar ideas have been implemented in other DBMSes, but when you take this list of strategies and put them into this kind of optimizer, the result has no direct equivalents in any other DBMS (or at least we believe so).

The first thing we did was to take a look at PostgreSQL as it is easily available and seems to have at least decent subquery handling (or even better than decent, I have not heard much complaints). And the first interesting difference was handling of correlated subqueries. With exception of materialization, MySQL's new subquery strategies do not care if the subquery is correlated or not.

For example, …

A bunch of (hopefully) self-explanatory slides about new subquery optimizations in MySQL 6.0 is available here (UPDATE: here's a working link). The slides are from this MySQL University session, so there was an audio stream but there were some difficulties with it and it is not available now.

If you miss the audio, the next opportunity to hear about this topic is the New Subquery Optimizations in MySQL 6.0 …

As I wrote earlier, we (me and Ranger) have done an assessment of the impact of new 6.0 subquery optimizations. First, we've done a search for performance issues in MySQL's bug database. The raw list is here, and the here is a summary chart:

Search for customer issues in MySQL's issue tracker system has produced a similar picture (raw list):

Search in DBT-{1,2,3,4} open source benchmark suites produced a radically different result though (raw data is …

I've finally found time to put together a couple of wiki pages describing what work we're doing for subquery optimizations in MySQL 6.0:

• The Subquery_Works page has an overview of what we've done so far, we're doing now and our future plans.
• The 6.0 Subquery Optimization Cheatsheet has a short, easy-to-read description of what has been released in MySQL 6.0.3. That should be enough if you just want to get the new version and see if your subquery is/can be faster now or not. If you want to know more details, the nearest occasion is my MySQL University session on February, 28.
• I've done a quick preliminary assessment of the impact of new optimizations. The …