A week ago I completely refreshed my MySQL Cluster setup (yea, been meaning to post on that) and was a little baffled when the 5.1.12 binaries didn't have the expected cluster programs (ndb_mgmd, ndbd etc). The earlier versions of 5.1.x I'd compiled from source so it had been awhile since using a binary, but on this refresh I didn't want to wait for the machines to configure and make.

When I couldn't find the cluster programs I chalked it up to failed memory, even though I swear I had seen something about the 5.1.x builds being more like the max builds of the past. I grabbed the source and forgot about it until today, when I came across this in the docs:

Due to a build slippage, binary distributions of MySQL 5.1.12 contain neither NDB Cluster nor Partitioning. We apologize for any inconvenience. Please upgrade to 5.1.13 as soon as it is available. if you build from source, you can execute configure with the --with-ndbcluster and …

Every place I have worked at has had the problem of "bad pushes". This means that at some point someone commits code which should have never been committed.

The specific problem I am thinking of is code that doesn't compile or breaks certain common criteria (aka valgrind warnings). Some of this you can automate out, but the automation systems never seem to be perfect.

The typical solution I have seen to solve this problem is either a "Wall of Shame" or "Who carries the pager". The pager method means that someone, normally the last guy who broke the tree, gets to be on call.

The "Wall of Shame" on the other hand is normally some sort of page on an internal website showing who the culprit is for bad pushes. Everyone will do this from time to time, but some people will float to the top, and its pretty embarrassing to have this pointed out.

I am not fond of methods which shame people. The …

Reading about Peter Zaitsev's feature idea about Finding columns which a query needs to access - which I would really like to see implemented - reminded me of a bug report I filed in 2004 and which bit me again only a few days ago. You can find it under Bug #7074 in the MySQL bug tracking tool. Although it is filed as a feature request, I think one should be aware of this, as it may cause problems in your applications (it did in ours).

Basically it is about explicitly specifying which columns you need in a result set, instead of just using SELECT *. This is generally a good idea, however if the table contains BLOB columns, it becomes even more important, as …

Reading about Peter Zaitsev's feature idea about Finding columns which a query needs to access - which I would really like to see implemented - reminded me of a bug report I filed in 2004 and which bit me again only a few days ago. You can find it under Bug #7074 in the MySQL bug tracking tool. Although it is filed as a feature request, I think one should be aware of this, as it may cause problems in your applications (it did in ours).

Basically it is about explicitly specifying which columns you need in a result set, instead of just using SELECT *. This is generally a good idea, however if the table contains BLOB columns, it becomes even more important, as …

Red Hat Plans to List Shares on the New York Stock Exchange, Red Hat (Press Release)

Red Hat ponders new JBoss strategy, News.com, Stephen Shankland (Article)

Seven tips for leading FOSS programmers, IT Manager’s Journal, Bruce Byfield (Article)

OSS Could Be Africa’s Answer, LinuxInsider, Bianca Wright (Article)

The patent cold war has begun, Libervis, Danijel Orsolic (Article)

…

Some numbers that came up this afternoon that I thought were interesting:

Number of clients running queries: 16
Average number of queries per client: 4516

For Memory:
Average number of seconds to run all queries: 2.269 seconds
Minimum number of seconds to run all queries: 2.218 seconds
Maximum number of seconds to run all queries: 2.302 seconds

For MyISAM:
Average number of seconds to run all queries: 2.268 seconds
Minimum number of seconds to run all queries: 2.268 seconds
Maximum number of seconds to run all queries: 2.268 seconds

For memcache, with Memcache on the same host:
Average number of seconds to run all queries: 3.576 seconds
Minimum number of seconds to run all queries: 3.576 seconds
Maximum number of seconds to run all queries: 3.576 seconds

Memcache, with two different hosts (full duplex):
…

OK MySQL planet. Hook me up. I'm waiting for MySQL 5.1.13 because I need the MySQL cluster ON DUPLICATE KEY UPDATE bug fixed. We rely on this for performance reasons so I can't to a test migration until this is out.

Anyone know the ETA?

Daisy-fresh from MySQL Camp, Jay Pipes hosts the 19th edition of Log Buffer, the weekly review of news from database blogs. Thanks, Jay! Lisa Dobson will publish next week’s edition on her Oracle Newbies Blog, and Adam Machanic’s data manipulation for fun and profit the one after. Editing and hosting Log Buffer is an great way [...]

This week's Log Buffer is dedicated to Jolt, Mountain Dew, and Google's Open Source Program Office, who treated the campers like royalty this past weekend at the first MySQL Camp. Leslie Hawthorn, from the OSPO, shed blood for the camp, and deserves the Congressional Medal of Honour for her valiant heroism! (She received 20+ stitches for a cut on her arm due to an accident carrying beer for a session on Saturday. )

MySQL Camp Highlights

MySQL Camp was a wonderful event, even if completely free-form at times. Sessions were lively, interactive, and participants really had a chance to dig in to session material and ask Monty, Brian, Mårten, and a host of other MySQLers good questions. …

In query examinations it is often interesting which columns query needs to access to provide result set as it gives you ideas if you can use covering indexes to speed things up or even cache some data by denormalizing tables. So far it has to be done manually - look at SELECT clause, WHERE clause, ORDER BY GROUP BY and HAVING to sum it up, not to mention more complex questions of subselects.

It would be great tool for MySQL Performance Optimization if MySQL Server could show this table and I know it already has this data as it is used by the optimizer.

It would be also good if such tool would show mapping of WHERE clauses to the tables as well as other clauses such as GROUP BY and ORDER BY. For complex queries especially if they do not refer to the columns with table prefix it may take a while to figure our where these columns come from and so how they can be optimized.