One of the best new features of MariaDB 5.2 is Virtual Columns.

What are virtual columns you say?

Well, I suppose I should start by backing up a bit and saying that there are two types of virtual columns: VIRTUAL virtual columns and PERSISTENT virtual columns. (I know, I know… saying virtual twice is a little strange).

Ignoring the semantics, I think of virtual virtual columns as truly virtual; their value is not stored and they have no actual existence apart from the table definition. They act like regular columns in queries, but their content is always calculated on the fly and never written to disk. You might be thinking that this could lead to a performance penalty; so to help with performance, if an SQL query doesn’t reference a virtual virtual column, the value is not calculated.

Persistent virtual columns are half-way between being truly virtual and being regular columns. The main difference compared to virtual virtual columns is that the calculated data is actually stored in the database.

More information on the syntax to use when creating a table with virtual columns, and some things to be aware of, see the Virtual Columns entry in the Askmonty.org Knowledgebase.

Enough talk, let’s see virtual columns in action.

Warning: The examples below are simplistic. In my defense, my job is to document how a feature works, not to wow anyone with all of the cool ways a feature can or could be used (and abused). Let me just say the examples work for my purposes here, but are not very useful, imaginative, or practical.

Tip: Don’t try to INSERT into a virtual column. MariaDB will just ignore you (and complain).

Now what happens if I do an alter table?

As you can see, the values in the virtual column were automatically updated based on the new virtual column definition. Pretty cool, no?

The alternative to using virtual columns would be to use triggers, but if you change your trigger, the old generated values will not be updated automatically. Granted this may be the behavior you need, but then again, it might not be. If you would like the generated data to be automatically updated, use virtual columns; if not, use triggers. In my opinion, virtual columns are much easier to update and maintain compared to triggers, but maybe that’s just me.

For example, consider a table with (among other things) a price_usd column representing a price in USD (United States Dollars) and a price_eur column representing a price in EUR (Euros). For the purposes of this example, let’s pretend the price_eur column is either a persistent virtual column or is filled by a trigger automatically. If you are using the table to record sales, you probably don’t want old entries to be updated if they represent the exchange rate between EUR and USD on the day the entry was entered, the the trigger-filled version is probably what you want since it will record the price in USD and EUR when the sale was made. On the other hand, if the table is used to record current prices, you will want all of the generated columns to be updated if the exchange rate changes, so the virtual columns version is the one you want to use.

Anyway, virtual columns is one of the nifty new features in MariaDB 5.2. Check it out!

Movin’ on up!
To the east side.
To a deluxe apartment
in the sky.

It’ s a bouncy, happy, gospel-flavored song. I always seem to think of it or hum it whenever I’m planning a move of some kind. The weird thing is, I never watched the show when it was on television. I saw the opening montage enough for it to stick with me, I guess.

So what’s moving over here? Well, the main server at Monty Program has been doing more than its fair share for a while, and it has done a decent job at it, but it’s time to give it a bit of a break, so we’re going to be moving some of its responsibilities to other servers over the coming weeks. The first service I’ve chosen to move is the AskMonty.org website. The move will happen on February 25th.

Thanks to the beauty of DNS, the move should be completely transparent to most users. There will be a brief period of read-only access while I copy the database from the old server to the new server, but that will only affect those that want to edit the wiki, or add things to worklog.

Of course, anything can happen during a move, so if you notice any weirdness on the site this Thursday, pop into #maria on freenode and let me or one of the other ops know.

Thanks!

Enabling Statistics

Statistics gathering is turned off by default in MariaDB 5.2. This is done to prevent the extra load on a server that this feature causes from happening unless you want it.

To enable statistics gathering, just put the following line in the [mysqld] section of your my.cnf file (or use it on the command line when starting the server):

userstat = 1

Now start (or restart) your MariaDB 5.2 server and statistics will be gathered.

Warning: If you switch back and forth between MariaDB 5.1.xx and MariaDB 5.2 (like I do on my MariaDB testing box), and use the same my.cnf file, be aware that the ‘userstat = 1″ line will not be recognized on versions of MariaDB prior to 5.2 and will cause errors.

Showing and Flushing Statistics

The User Statistics SHOW commands supported by MariaDB 5.2 are:

SHOW CLIENT_STATISTICS
SHOW USER_STATISTICS
SHOW INDEX_STATISTICS
SHOW TABLE_STATISTICS

If you want to restart the counters on any of these (like after you roll out a change to your application) you will find the following FLUSH commands handy:

FLUSH CLIENT_STATISTICS
FLUSH USER_STATISTICS
FLUSH INDEX_STATISTICS
FLUSH TABLE_STATISTICS

Information Schemas

The above SHOW and FLUSH commands are just easy ways to view and flush the actual statistics, which are stored in the information_schema database. Specifically, statistics are stored in the following tables in the information_schema database:

CLIENT_STATISTICS
USER_STATISTICS
INDEX_STATISTICS
TABLE_STATISTICS

The CLIENT_STATISTICS table stores information such as the number of concurrent connections from a particular client, the number of rows read by a particular client, the number of SELECT or UPDATE commands executed by a particular client and so on.

The USER_STATISTICS table stores the same information as the CLIENT_STATISTICS table, but on a per user basis.

The INDEX_STATISTICS table stores statistics on index usage and makes it possible to do things like locating unused indexes and generating the commands to remove them.

The TABLE_STATISTICS table is similar to the INDEX_STATISTICS table, but contains statistics on table usage such as the number of rows read and changed in a particular table.

More Information

Detailed information about User Statistics in MariaDB (including schemas for the various tables) is available on the askmonty.org website: http://askmonty.org/wiki/index.php/Manual:Userstat

At Monty Program we’ve been guilty of this. Up until a few days ago our main website, askmonty.org, was running the stock MySQL server from our chosen Linux distribution’s repositories. This was mainly done for system administration simplicity. However, MariaDB now has Debian, Ubuntu, and CentOS packages available for download and we saw no reason to not eat our own dog food. Yes, we could have taken the time to create custom build of MariaDB just for our own use even before our first beta releases, but like the barber with the bad haircut and the cobbler’s children with no shoes we are too busy improving MariaDB to focus on geeking up our web server with custom builds. For our production servers we would rather use standard packages like nearly everyone else on the planet. Why? So that we can focus on doing what we do best: making MariaDB the best version of MySQL you’ll find anywhere.

So how did the upgrade go? Swimmingly. There were a couple glitches due to some historical weirdness on our web server, but once those minor issues were resolved the install of the beta MariaDB packages was trouble-free. It just worked. All of the MySQL databases on the server were in perfect working order after the upgrade with the exception of a single table in one of the databases which was easily fixed with a “REPAIR TABLE dbname.tablename;”.

Oh, and before you ask: I performed a full backup of all of our databases to an external drive prior to doing the upgrade. I trust MariaDB as much as anyone can, but power outages, lightning strikes, earthquakes, floods, and even meteors hit Finland at the exact wrong time every once in a while and it would be just my luck to have one of those happen during an upgrade.

In conclusion: Monty Program is now eating its own dog food, and it’s awesome.

29 May 2009 will be my last day at my current employer. Global Knowledge has been good to me these past four years. I’ll miss working with the people in my group. It is a very Linux and Open Source friendly group and I’ve learned a lot while I’ve been here.

So, where will I be going? Funny you should ask…

For those of you familiar with databases, Michael (Monty) Widenius is the founder and original developer of the MySQL database. The database is named after his daughter, My. In 2008 he sold the database and the MySQL company he co-founded to Sun Microsystems. After being at Sun for a few months he decided to leave. The MySQL database is Open Source software, so he was able to create a branch of MySQL called MariaDB (Maria is Monty’s other daughter).

Starting on 1 June 2009 I will start working as a technical writer and sys-admin for Monty Program Ab, the company Monty set up to develop and support MariaDB.

I’m very excited for this new opportunity and while it will bring lots of changes one thing that won’t be changing is our address. We’re staying right where we are.