Some might've noticed that the check-cpu script in the MySQL BUILD directory does not always succeed in detecting the right processor:

roland@roland-laptop:/opt/mysql/5.1/bitkeeper/BUILD$ ./check-cpu
BUILD/check-cpu: Oops, could not find out what kind of cpu this machine is using.

When you dig a little deeper into that script, you will notice that the name of you particular processor (in my case: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz) is indeed not there and thus not checked. Finally you may find that the model and name of your processor are passed to the gcc compiler.

As far as I cans see the information is used to set the values of the --mtune and --march compiler options. What those are? Hehe! Ok, here's a partial result from man gcc:
…

At the end of my last MySQL post I mentioned strange behavior with GROUP BY and DISTINCT. In Oracle such constructions are not valid and produce an error. Here is the test table and statements:

create table t1 (c1 int, c2 int);

insert into t1 values (1,10); insert into t1 values (2,20); insert into t1 values (3,30); insert into t1 values [...]

I hear a lot of people say: "Well, compiling MySQL from source might pose a problem to Windows users, but it's straight forward for Linux users." Quite often, the difference is explained by claiming that Linux users are used to doing things themselves, and gaining an extra bit of customization by doing so.

My impression is that a large part of the people that say this, are already quite experienced Linux users that are quite comfortable with compiling software from source. The entire toolchain that is involved is already set up on their system, and some of them probably already forgot what they had to do in order for it to make it work.

What is quite often not mentioned is that the required toolchain does not magically land on your system. If you are experiencing prolems compiling MySQL source it's quite likely the toolchain …

What a great day was had with the miniconf this year! Many people thought that there would be few people coming, or there would be issues having the PostgreSQL miniconf the next day, but it went better than could be expected.

The morning sessions were so popular it was standing room only as some of the great talks went out to an enthused audience. I was more nervous than usual delivering a talk on MySQL cluster with Stewart Smith being in the same room (he is a developer of the ndb engine with MySQL at the moment). My fears were relieved when Stewart gave me the "thumbs up" after the talk and thought it was quite good. Phew!

So was there any downside to the day - unfortunately yes. There were an over-abundance of talks submitted so some people did not have an opportunity to present. I actually submitted two talks - one on ndb cluster and one on the Sphinx search engine. Only one was accepted due to the excellent submissions made for …

Late in 2006 MySQL decided to move to a split distribution model, Community and Enterprise. A lot has (apparently) changed since then, yet nothing has really changed since then.

I'm subscribed to a lot of mailing lists - PHP, mod_perl, MySQL, web application security, etc. This week, there was an interesting conversation on the NYPHP mailing list - consulting rates.

It all started with an email from Edward Potter. He had previously emailed the list to inquire about consulting rates and was sharing the results with everyone:

Just to keep everyone up to date, based on interviews to …

I'm subscribed to a lot of mailing lists - PHP, mod_perl, MySQL, web application security, etc. This week, there was an interesting conversation on the NYPHP mailing list - consulting rates.

It all started with an email from Edward Potter. He had previously emailed the list to inquire about consulting rates and was sharing the results with everyone:

Just to keep everyone up to date, based on interviews to …

MySQL statement-based replication is widely discussed, but I haven't seen much about how to design a replication setup for low downtime and easy administration. Statement-based replication has inherent shortcomings experienced MySQL users know to avoid, but rarely write about. This article explains how to avoid problems, help your slaves stay in sync with the master, and recover from disasters more quickly.

About an hour ago, I got back from Washington, DC after spending four days attending a very productive MySQL performance tuning training session. I really enjoyed conversations with old and new friends including:

• Tobias Asplund, Instructor
  
• Ronald Bradford, Senior Consultant MySQL Inc.
• Michael "Mike" Amedeo Alaimo, IT Manager, Distributive Networks
  
• Stephen Spitzer, Learning Resource Center, USUHS
• Nyk Cowham, Systems Architect, Forum One Communications
• Joe Mansour, Web App. Programmer, and Donnie Lynn, DBA, Computing Center, …