Just got back from the MySQL DevCon in Sorrento, Italy, followed by a fortnight's working holiday in Bangkok. The day before I left Italy, I received a 5AM call advising me that someone had broken into the house (again). My useless sod of a rental agent was reported to have said, "If he thought he might get broken into, he oughtn't have gone overseas." WTF? I was supposed to ring up our CEO and tell him, "Hey, Mårten, you don't mind pushing back the conference about six months until Yong Property Management (pathetically negligent) decide to pull their finger out and do something about the shoddy locks on the windows and doors of that piece of crap I pay them $300 a fortnight for, do you?" Right! Those losers couldn't even be bothered to come secure the door after the fact. If it'd not been for my yard guy and my housekeeper taking matters into their own hands and doing something about my back door having the glass bashed out of it and gaily …

Why when running doxygen over the mysql tree (5.0 or 5.1) do I have a process with 590MB of RSS memory?

Not exactly inspiring confidence. Although I guess I’m lucky because I have the RAM to do that in (on any box around here I actually use frequently).

The output of doxygen can be really useful when trying to learn (or remember) the relationships between various bits of code. I find it a bit faster than switching between buffers in an editor and then trying to remember where some class was defined. links are a good thing.

It’d be great if we switched all our public API docs to doxygen, as the output really is quite nice. In fact, internal APIs wouldn’t be bad either. Although, naturally, the real documentation is the source, which (luckily) the doxygen output also makes easy to view.

I’ve rigged up this script to automatically pull the latest out of the public repository (using the free …

So before I launch ~40 benchmarks across six identical (plus one not identical) machines running on different RAID setups, I have to ask something...

Does anyone just know the best BIOS/RAID/kernel/scheduler/MySQL 5.0 options for SMP x86_64 hosts running large amounts of memory (8G+) doing lots of varied writes/reads with 95% InnoDB data? Willing to share? :)

I have a pretty good idea of the BIOS/scheduler/MySQL options, probably kernel, less so on the RAID front. I have LSI megaraid U320-1LP's with 64 megs of cache with battery backup. Six drives per machine, not bothering with hotspare. Will have coldspares around.

Also, fun shit: In at least 2.6.15.7 and 2.6.16.1, if you have all of the adaptec drivers *and* new LSI drivers compiled into your kernel, and have the same LSI megaraid cards that I do, weird shit happens. 9/10 times during boot megaraid_mailbox will fail to probe the hardware all the way, …

After several months of back and forth negotiation, MySQL and Oracle have agreed to a multi-year extension to the existing contract enabling MySQL to continue to sell and support the InnoDB storage engine.  The terms of the agreement are very much "business as usual" for both companies.

This is good news for MySQL customers and for the open source community, and it reinforces the message that Oracle President Charles Phillips stated to us when they acquired InnoDB that they intended to renew the agreement.  And since InnoDB is GPL, freedom for users is guaranteed, no matter who owns the source code. 

The key guy to help drive this agreement from Oracle's side was Ken Jacobs.  Through a long series of meetings, some more challenging than others, Ken kept a cool head and continued to keep us all progressing …

this is the output of dtrace -n 'pid$target:::entry{ @[probefunc] = count() }'

when I run mysqlslap -c 20 -i 20

  pthread_getspecific                                             365
  malloc_internal                                                 377
  my_malloc                                                       377
  free                                                            378
  malloc                                                          378
  my_wc_mb_filename                                               399
  my_no_flags_free                                                420
  strmake                                                         444
  pthread_self                                                    468
  memset                                                          582
  alloc_root                                                      630
  strmov …

So I'm in Boston at LinuxWorld this week (though not today) and have met a number of interesting people so far. Of particular note, I had a great conversation with Clint Oram, co-founder of SugarCRM, regarding community relations, forges, and open source in general. He's one smart cookie, which is one of the reasons he's doing a session at this year's Users Conference about optimizing SugarCRM to work best with MySQL

One of the things we discussed was the success of SugarForge and ways in which the (very alpha) MySQL Forge and SugarForge might be able to share content. For instance, the MySQL Forge wiki could have a number of articles tailored to …

• Open source is not a marketing toy.
• Open source is not a way to get people to visit your site or to push your legacy tools.
• Open source is not just choosing one of the OSI approved licenses.

These are not the reason why people trust in open source applications.

• The reason is that peer review results in superior code.
• In code that is flexible that we can integrate as needed.
• Code we can poke and discuss.
• Code we trust because we know technical reasons are the single most important steering guideline.
• This process is why we think it is worth our time to provide free QA, support and advocacy for open source applications.

Now why am I ranting like this?
Zend has officially proposed a PHP IDE for eclipse (PHPEclipse is not an official Eclipse project) and they are certainly poring in development resources which cost them …

Assume nothing. Your assumptions are wrong, that’s why there’s a bug silly!

If valgrind had a time machine function it’d be totally awesome. But it doesn’t so currently extra work and thinking is required. doh!

I’ve had to fix a few small bugs in the release of phpbms. So I’ve put my bzr archives up

bzr clone http://www.flamingspork.com/src/bms.upstream/

and

bzr clone http://www.flamingspork.com/src/bms.stewart/

Hopefully there’ll be another release soon that incorporates these fixes - some are on the sourceforge page and some are in the source repo.

BUT... Create the sub-tables exactly as you would for a MERGE table. Note the indexes.

create table chunk1 (num int, data varchar(255), key (num));
create table chunk2 (num int, data varchar(255), key (num));

Create a VIEW that is simply a UNION of the data sets of the sub-tables.

create view chunk as select * from chunk1 union select * from chunk2;

Create another VIEW that aggregates the sizes of the sub-tables.

create view counts as
      select count(*) as records, 1 as chunk from chunk1
union select count(*) as records, 2 as chunk from chunk2;

Now a cool thing - use the counts VIEW to implement round robin INSERT operations for automatic load balancing between chunk tables. Extra cool if the FEDERATED engine is used for the sub-tables:

<?php
function next_chunk() {
    $rs = …