Good news: Ivan Nikitin is feeling better all the time. He has gone through insightful treatment in Heidelberg, and he is responding very well to it. The best part is that while the donations aren’t yet sufficient for a transplantation, it does look as if a transplantation may not even be necessary; the German doctors give Ivan’s body a chance to regenerate by itself, and it worked. And the generous donations from MySQLers, from classic Sun employees and also from the MySQL user community have made Ivan’s treatment in Heidelberg possible, something for which we are all very grateful.

Ivan Nikitin in Georg Richter’s lap (in Georg’s boat)

Ivan’s father Andrii allowed me to publicly quote his email to MySQL employees:

Hello MySQLers,

Ivan’s condition goes with most optimal scenario - doctors think he will not require transplantation because he …

To be fair - I highly doubt it has anything to do with MySQL.Database corruption - that's a different issue, often related to a bug in database code; but this was a data corruption issue, which is always a pain in the you know what to figure out and get fixed.I spent the last day trying to figure out the weirdness in a couple of our databases, digging around, explaining to developers that

Although we haven't announced any new members in a while, the Percona team has continued to grow steadily behind the scenes. Our hiring policy is to have a few months' provisional period to ensure the absolute highest quality of service and consistency of results provided to our clients. Today I'm proud to officially welcome Ewen Fortune and Piotr Biel, who have been working with us for quite a few months.

Ewen Fortune joins us from Spain, where he lives with his family. Ewen is actually a native English speaker, but is fluent in written and spoken Spanish, of course. Ewen has been a consultant and contractor before joining Percona, and has many years of experience in Oracle, MySQL, Unix systems administration, programming, and networking. Ewen is an Oracle Database 10g Administrator Certified Professional (OCP), a Certified MySQL 5.0 DBA (CMDBA), and a Certified MySQL 5.1 Cluster DBA (CMCDBA). Like all of our consultants, he also has some …

The client du jour has a table with a column that keeps phone numbers. This is normal.

However, the column is a varchar(255) charset UTF8.

This is not okay.

In MySQL, that will take up 765 bytes per row in memory, plus will be doing UTF8 to to 3byte expansion for every row read or scanned. And it has to use the wchar string ops to do comparisons.

The ISO standard for PSTN phone numbers, E.164, states that phone numbers are a max of 15 digits long, and that includes the country code.

Make phone numbers a varchar(16) charset ASCII. Have your application mash out all the spaces and hypens.

Then marshalling and expansion is free, and modern processors can do an equality test against 16 bytes in a single operation.

16 bytes vs 765, that's a 50x savings.

Oh, and stop assuming that all phone numbers are in the US and Canada, and thus …

I really like this post by WaveMaker CEO Christopher Keene, deconstructing Larry Ellison's aversion to cloud computing.

Larry's rant is an extraordinary example of whistling past the graveyard. Oracle's huge transformation over the last 10 years has been from an infrastructure company (databases & middleware) to an ...

I really like this post by WaveMaker CEO Christopher Keene, deconstructing Larry Ellison's aversion to cloud computing.

Larry's rant is an extraordinary example of whistling past the graveyard. Oracle's huge transformation over the last 10 years has been from an infrastructure company (databases & middleware) to an ...

I have some ideas already.

A tutorial on partitions

Since I have done much testing and writing on partitioning, I feel the need of presenting something in public. Performance, administration, use cases, are all aspects of partitioning with which I am well acquainted.

Row-based replication …

A while ago, MySQL developed a Community Contribution Agreement for community contributions to the MySQL source code. While browsing the MySQL Forge Wiki I came across:

http://forge.mysql.com/wiki/Community_Contributions

This page shows that the Community Contribution Agreement has changed — it is no longer the document MySQL AB created. It is now Sun Microsystem’s standard Sun Contributor Agreement, which CEO Mårten Mickos recently explained to me was “more accepted than the agreement MySQL had come up with.”

I am happy to see some of the great Sun practices trickle down to replace some issues that MySQL did not handle smoothly. All in all, I agree with Mårten Mickos and think the Sun Contributor Agreement is much better….

….but what do you think?

Finally I have the site up and running!!!!!!!!!!!!!!

I registered this domain a week back and was looking for a webhost to host the domain. Thanks to Jithin from Ndimensionz.com for providing me this space.

You can expect few blogs on my MySQl experiments in the coming weeks.

Signing off for now

First, a retraction, it turns out that the performance problem with datatimes in the previous article wasn’t due to high cardinality (I speculated too much here), but due to a type conversion issue.  From a helpful comment from Victoria Eastwood of Infobright (a good sign for a startup), the Infobright engine considered ‘2001-01-01’ to be a date, not a datetime, and it couldn’t do a conversion to a datetime.  Instead it pushed the date filtering logic from the Infobright engine to MySQL.  Effectively, the slow queries were a table scan.   The solution is to add the 00:00:00 to the dates to make them datetimes.  

With that in mind, here are some much better numbers for Infobright.   For Infobright this query took 0.05 seconds. 

1) Select sum(unit) from Sale where purchaseDate >= '2001-04-01 00:00:00' and purchaseDate < '2001-05-01 00:00:00'

This compares very …