I have had a wish for a few years. I wanted to find a way to put together the valuable information that the community produces about MySQL, a way that would let me easily find the interesting content that I may have missed when on vacation, or when busy with a conference, a company meeting, or a long stream of coding.

That wish started to take shape last year, when I was traveling with Dups during the East Coast tour. I drove, he took notes. He drove, I took more notes. During meals and walking breaks we discussed and refined the idea. When we went back home, a plan was ready. Dups started coding in January.

At first, his changes were completely invisible. He was refactoring the Planet MySQL code to integrate it with the advanced features that had been developed for the main site. After a series of secondary changes, there came the substantial one. The voting …

I was asked recently in one of my blogs what are some of the pure technical advantages of moving from MySQL to Oracle. I kind of laughed when I read the question because nothing is likely to stir up more perspectives and emotions than asking about moving from one database server vendor to another. So here goes ten technical considerations of moving to an Oracle database server from a MySQL

Finally merged into main. I added the ability for engines to be temporary only – that is you can only CREATE TEMPORARY table or be created and used during query execution. This allows us to refactor/remove some other code and go towards a “locking is inside the engine” mantra as anything but row level or true MVCC is certainly the exception these days.

Forrester put out its Enterprise Data Management Q2 2009 report a few days ago, you can buy it from Forrester but it also seems to now be available for free from Microsoft here.  I don’t actively seek out these reports as they usually just re-enforce common knowledge (this one was no exception), however as it turned up I managed to find some time on the weekend for a quick read through.

Few surprises in this report, but some key mentions are:

• DBMS market expected to grow 8% annually
• IBM, Microsoft & Oracle own 88% of the DBMS market (by revenue)
• Current market estimated at $27 billion, $32 billion by 2013
• IBM, Ingres, Microsoft, Oracle, PostgreSQL, …

Open SQL Camp will be organized in St Augustin, Germany on the weekend of 22-23 August. Unfortunately, at Monty Program, it looks like we have already scheduled a company meeting at the same time and all of us will be in Spain instead. Consequently, there are now no MariaDB talks proposed for the conference, which is a shame.

read more

Among other things, these past few months I have been working on setting up Buildbot, including adding various enhancements and bug fixes that are needed to properly build and test the MariaDB and MySQL code base.

Since Buildbot is written in Python, this means I have also had to learn Python. I am an old-time Perl hacker, so this exercise feels a bit like living in enemy territory ;-)

Anyway, Python is often touted as a more "pretty" language. And in many ways it is. Still, it is not without its own gotchas. Think "scope rules". Obviously someone haven't been reading up on the subject before implementing things in Python, causing the language to behave stupidly (and certainly different from what one expects) in the following three cases that I hit during my Buildbot work.

First …

The MySQL KILL command as the name suggests kills queries that are running.

After identifying the Id using the SHOW PROCESSLIST command, the User of the connection/thread or a database user with SUPER privileges can execute KILL [id]; to remove the connection/thread.

However, there is an ability to kill just the query that is being executed rather the entire connection. The default when not specified is to kill the connection, however you can optional specify the CONNECTION or QUERY keywords.

For example, below is an interactive test.

Thread 1:

mysql> select sleep(10);

Thread 2:

mysql> show processlist;
+----+------+-----------+------+---------+------+-----------+------------------+
| Id | User | Host      | db   | Command | Time | State     | Info             | …

I've been working on cleanups to the Drizzle autoconf and automake system. Actually, to be fair, I've been doing this work on Drizzle, Gearmand, libdrizzle and libmemcached.

In all of those projects, we have the same set of build ideas:

1. Warnings == Errors
2. As many warnings as we can enable
3. Lots of people will be building directly from bzr

As it turns out, I'm pretty lazy, and I got tired of remember to port the latest m4 macro fix that we made in one project across to the other three. O, hai - code reuse!

So I did some refactoring and split the several macros and large portions of the configure.ac files out into a set of m4 macro files. These now live in their own project, which you can grab from bzr via:

 bzr branch lp:pandora-build

Although each of the macros is useful by itself, the fun part is that you can just put:

…

Today we increased price for the Amanda Enterprise Backup Server. The new price for our Standard subscription level is $500 per year. Our online store is a place to quickly checkout prices for all our products on a single page. This price increase was done in conjunction with release of Amanda Enterprise 3.0, which represents several man years of R&D on the backup server, including advanced media management such as D2D2T. Our subscription provides access to software and enterprise-class support.

Amanda Enterprise is used by businesses of all shapes and sizes. But a typical scenario is the following:

• Backup Server on Linux
• One tape library with one or two tape drives. Or VTL on a NAS device.
• A mix of Linux & Windows servers and desktops …

Eric McDermid just checked in a nice new feature into Mondrian which optimizes the SQL generated by MySQL. It takes advantage of the fact that in MySQL, if some of your GROUP BY columns are unique, you can leave the other columns out of the GROUP BY clause, and MySQL does less work.

In some cases, a lot less work. MySQL implements GROUP BY by sorting, and since this reduces the volume of data being sorted, Eric reports significant performance improvements. Unfortunately it only works on MySQL, since MySQL is the database I know which has this feature.

See the latest schema documentation for more details.

I'll note that we reserve the right to change the syntax a little in future versions. In mondrian-4.0 we're adding physical schemas, which will include much more information …