I had a nice dinner with Monty Widenius, co-founder of MySQL the other night.  Monty is an excellent cook and he prepared a nice meal for the team that has been working at his house in Finland the past few days.  It was nice to spend time with everyone and drill into some of the interesting new development that's taking place.  We also talked about ways we can improve our processes, code quality, QA and cooking.  I recorded some of the discussions and will try to transcribe it into an interview on the developer zone. 

Update: The interview is now posted.

• MySQL: …

Don't forget to register for ApacheCon Europe before June 6 to receive the early bird discount. This is also when the conference organizers decide which tutorials to keep, so don't wait until the last minute to sign up for your favorites, else you might be disappointed to find out that they're no longer available.

The discounts are pretty good - 349 euros for a full-day of tutorials. (309 if you send three or more people.) Speaking of tutorials, there are some good ones to choose from, and OmniTI is well represented:

• Monday, Advanced Production Troubleshooting Techniques by Theo Schlossnagle …

While the majority of the really serious and crashing bugs are fixed right now in MySQL 5.0, there are still a lot of bugs that only surface in some very specific queries. One area that seems to be more heavily affected in particular are VIEWs.

To keep track of the ongoing progress I just compiled a list of my VIEW bugs that have just been fixed with the current releases or are probably going to be fixed in one of the next. Interestingly, I hit five of them (#19077, #19089, #19111, #19114, #19714) with just one single set of nested VIEWs. I bet you believe me, that it took me some time to figure out why my final query just wouldn't return the result I expected.

Bug #15950 (no schedule for fix available yet)

Functions returning the current date or time (such as NOW()) get optimized …

As part of the partitioning development in MySQL 5.1 we've added the ability to
check which partitions of a table that is actually accessed in a particular query.
As partitions in a sense can be a sort of index this is an important feature to
help understand performance impact of a query.

The method to use this feature is the normal EXPLAIN command with an
added keyword PARTITIONS. So e.g.
EXPLAIN PARTITIONS select * from t1;

So a slightly more useful example would be
CREATE TABLE t1 (a int)
PARTITION BY RANGE (a)
(PARTITION p0 VALUES LESS THAN (10),
PARTITION p1 VALUES LESS THAN (20),
PARTITION p2 VALUES LESS THAN (30));

Now if we do an equal query we should only need to access one partition:
This will be verified by the command:
EXPLAIN PARTITIONS select * from t1 WHERE a = 1;
/* Result in p0 being displayed in the …

As part of the work in developing partitioning support for 5.1 a new
information schema table has been added. This table can be used to
retrieve information about properties of individual partitions.

To query this table you can issue a query like:
SELECT * FROM information_schema.partitions WHERE
table_schema = "database_name" AND table_name = "name_of_table";

The result of this particular query will be one record per partition in
the table with info about the properties of these partitions.

A query on a non-partitioned table will produce a similar output
although most fields will be NULL. The information_schema.partitions
table is not yet implemented for MySQL Cluster so for MySQL Cluster
tables the output will be all NULLs on the partition specific information.

Below follows a short description of the fields in this …

Ok, so it's only in the architecture stage... but the great news is, we're already publishing the info so we can get early feedback before implementation starts. I think that's a fab development. Greg Lehey is leading this project.

You can find the review document here: OnlineBackup (on the MySQL Forge Wiki).

This feature will implement a way to make complete online backups (i.e., from a running server), regardless of which storage engines are being used. A backup will also be consistent across multiple engines.
And the idea is to make it a stream, so it can be sent straight through gzip/bzip, or tape or some other sequential archival device. This is excellent for very large data sets, of course, as there wouldn't be space for …

As part of both my UltimateLAMP side project, and my greater involvement with MySQL Workbench, I’ve been wanting to review and document the database schemas of Open Source products.

Indeed, as part of discussions with Mike Zinner of MySQL AB at the recent MySQL Users Conference, I suggested an idea used in the Java World, for example by Clover and Agitar, where to promote the usefullness of their respective tools (in this case code coverage), they provide results against Open Source Products. For an example check out Clover Examples.

With MySQL Workbench, to get some greater …

This interview took place with Monty Widenius, co-founder of MySQL, at his house outside of Helsinki, Finland. In Montyâ??s usual understated Finnish style, we talked about MySQL 5.0, coding styles and cooking.

In this issue of the MaxDB series we will introduce you to some selected aspects of transactions. The topic of transactions seems pretty boring. But in fact it depends very much on the point of view you take. We have tried to put a light on the subject that shows some rather advanced aspects of transactions which are a little less often discussed in database classes.