Interesting enough this year people at OSCON do not show to much interest in the MySQL, and Databases for that reason. Our talk comparing performance of MySQL Storage Engines had probably 20-30 people, Monty's talk on MySQL Source Code had about same number, and as Monty told me he never had so few people on his talk. This is from massive 2600 people attending the conference.

The other Database related talks I visited had similar size of audience - talks on migration To and From MySQL, Josh Berkus talk on Performance Optimization (this one if about full stack), Developing using SQL Lite. On other hand front end related talks such as PHP performance optimization or High Performance JavaScript were attended extremely well.

MySQL BOF supported by bear and pizza had about same number of attendees. With a lot of familiar faces.

MySQL booth was not to active ether - in many cases I could see lonely Kelly sitting on it. But This …

Crap!

     37 if (args->arg_count == 2)
     38 {
     39         strncpy(message, USAGE_ID3_PARSE, MYSQL_ERRMSG_SIZE);
     40         return 1;
     41 }

The problem with using code in talks?

You find bugs!

And what happens when you find bugs?

You want to fix them.

And fixing bugs is more fun then doing slides...

A

So, last night a group of us sat down and went through all the mini-conf proposals for linux.conf.au 2008

There were a lot of proposals. There were also a lot of good ones.

We’re not announcing anything yet… but in the interest of openness… here’s the procedure.

We started out as any responsible group of selectors would…. looking at the proposals over beer:

a few jokes thrown in… frank discussion and all that. But really, we came to the conclusion that it’d been all done before and we needed to somehow narrow down all the excellent suggestions…

Luckily, the pub we were meeting at had the right …

For those who may not have noticed, I was suckered into asked to take over part of Matt Asay's former blog over at InfoWorld when he fled the coop moved his blogging over to CNet.  Both my old blog (that's this one, www.theopenforce.com) and the new one are aggregated at PlanetMySQL so for many folks this may not be any big deal.  I will continue to post occasionally on this blog, but most of my postings will be done on the InfoWorld site for now along with co-conspirators Dave Dargo, Savio Rodrigues, and Dave Rosenberg.  It's just too much work to maintain two blogs at the same pace.

Here are some of the recent stories I posted at Infoworld:

• …

The huge power outage at 365, affecting such sites as craigslist.org and Yelp, brings to mind some important thoughts about redundancy and infrastructure. Of the many sites at 365, including both new, interesting startups and more mature sites, how many survived the power outage well? More importantly, did they lose power on their databases, and then did they lose any data?

It's easy to believe in your provider when they assure you of uptime, redundant power, excellent cooling, and whatever else they promise to get your business. But you really shouldn't, and this is an example of why. You must have multiple sites! Preferably geographically diverse (nothing hurts like an earthquake or hurricane taking out your main data center and your redundant data center at the same time).

MySQL, sadly, is not a durable database when …

Mike Olson pointed me to this excellent Wired article on the disappearance and search for noted database researcher Jim Gray. Jim is apparently the sort of developer that every company on the planet wanted to hire. At this point, no one wants him more than his family. Yet he's ...

One of the most popular keynotes of the MySQL Conference & Expo 2007 was called "The Clash of the DB Egos". It was a fight amongst seven database luminaries, all playing an important role either within MySQL AB or as providers of Storage Engines that work closely with MySQL. This article attempts at giving a picture of what the fight was about, through reciting the egos and the questions posed to them by the referee.

After several months I have again spent a little work in the MySQL Index Analyzer I first published back in August of 2006.

I added a feature that will find duplicate columns inside an index, caused by the internal appending of the InnoDb primary key columns to each secondary index.

To get the code and read more about the new feature, including an example, go to the MySQL Index Analyzer Blog.

I came up with the following trick in response to a question in the #mysql channel on Freenode. A user needed to create a unique identifier for multiple otherwise duplicate entries. Yes that was bad schema design to begin with, but it was a fun challenge to see if it could be resolved without scripting. And it can... it's based on a known trick of numbering output rows. What's new is restarting the counter for each group (name).

CREATE TABLE number (name CHAR(10), val INT DEFAULT 0);
INSERT INTO number (name)
     VALUES ('foo'),('bar'),('foo'),('foo'),('bar');

SET @lastval=0, @lastuser='';

UPDATE number
   SET val=(@lastval:=IF(name=@lastuser,@lastval+1,1)),
       name=(@lastuser:=name)
 ORDER BY name;

SELECT * FROM number ORDER BY name,val;
+------+------+
| name | val  |
+------+------+
| bar  |    1 | 
| bar  |    2 | 
| foo  |    1 | 
| foo  |    2 | 
| foo  |    3 | 
+------+------+