Like others we were not satisfied with the fix for a bug in MySQL which caused the query cache and partitioning to not work reliably together. The bug, in simple terms, was that if the query cache was enabled and you used partitioned tables and if a partitioned table was using a transactional engine like InnoDB or XtraDB, the query cache could, under certain circumstances, return incorrect results.

Returning incorrect results is a definite, high-priority bug. However, the upstream fix was to disable all caching of queries from partitioned tables. We wanted a better solution because the query cache can be very useful and beneficial for partitioned tables, just like it is useful and beneficial for non-partitioned tables.

The root of the problem was that the query cache did not have any visibility into partitioned tables. In particular it didn’t know anything about a given table’s storage engine, including if the table was transactional or not. This lack of information prevented the query cache from intelligently caching and returning the cached results of queries.

We solved this by creating a way for the query cache to talk to the underlying storage engine of a partitioned table to see if it is:

  1. OK to cache the result of a query
  2. OK to return a cached result

With that information in hand the query cache can now properly cache new queries and provide correct cached results for duplicate queries every time, no matter if the table is partitioned (or not), or transactional (or not).

The patch is already in the MariaDB 5.5 source on Launchpad and will be in our next release of MariaDB 5.5.

Update: Monty has also written about this on his blog.

A screencast about the MariaDB release process.

MariaDB Screencast – The MariaDB Release Process
Watch this video on YouTube.

(I recommend watching it in full screen 720p, so you can see the details.)

Some links mentioned in the video:

It is not a secret that we’ve been kicking the tires and playing with JIRA for project management. After using it since the beginning of the year most of us like the feel of it and we’ve decided that it makes sense to start using it more.

As you know, the MariaDB project has many fragmented resources. We report bugs in Launchpad. We store our plans in worklog. We’ve never used the Launchpad Blueprint feature for this very reason. We don’t use Launchpad Answers because we have the Knowledgebase.

With this move to hosted JIRA (yes, this is an important link: http://mariadb.org/jira) we can report bugs, have future plans, and also give users a roadmap which is pretty cool. One nifty feature is that in the past two releases, we had a roadmap and we didn’t slip in terms of a schedule. We had on time releases and that’s awesome!

So what does this mean for you? To report bugs, you will now do so on JIRA. To make feature requests and talk about our future plans, you will also now use JIRA.

We plan to deprecate Worklog and Launchpad bugs by 30 June 2012. Launchpad will however continue to host the source code for MariaDB.

What will happen to bugs already reported on Launchpad? We have migration scripts ready for this and when we press the button bug reports will nicely migrate over to JIRA. After that is done we’ll place a notification on the MariaDB bugs page in Launchpad about reporting new bugs in JIRA.

What will happen to feature requests and ideas already in worklog? Worklog will be put into a read-only mode and there will be notifications about the move to JIRA. Whenever needed we’ll copy & paste worklog items into JIRA.

What does it mean to the openness of the MariaDB project? It’s not affected at all. The MariaDB project will remain an open community friendly project and as a bonus it will be easier to follow what is going on in the project since you don’t have to jump between several tools to get the complete picture.

The consolidation to JIRA provides the means to report and track project status easier than before, which allows the MariaDB team, community members and other to better coordinate and prioritize work.

As a side note, JIRA (and other software by Atlassian) has sometimes been criticized in the open source world because of its commercial nature and many are unaware of the fact that Atlassian do offer a free Open Source Project License to open source projects, which is what is being used with MariaDB.

As another side note, I’m not going to dive into comparing features in e.g. Launchpad with features in JIRA. I do know it would be possible to use blueprints for feature specifications etc. in Launchpad. The most important aspect in my mind is that you pick a tool that you like the feel of, has the features you need and tightens collaboration between developers, project managers, community members and other persons involved in the project.

In short, this is all about three project tools becoming one.