A current project which now includes the use of PHP, MySQL Stored Procedures, recursion, temporary tables, etc., and some of the issues encountered along the way, leads me to write up these notes to share with others. Hierarchical datasets have been discussed before, and the means to traverse them in SQL. This current dataset is not hierarchical, not even a partial ordering, but a network, somewhat along the lines of a social network. In this instance it is musicians who play for bands, and creating an extended network by following up on other bands that musicians played for, and also researching all members of a particular band that a musician is a member of, ad infinitum or at least to maximum recursion depth, currently set at 25.

Right now the stored procedures consist of two: a non-recursive function that creates a temporary table and makes the initial call to the recursive procedure. No resultsets are returned; the PHP script that …

It's really hard for me to believe how time has just been flying. Ever since I got back from the very awesome MySQL Camp at Google headquarters, I have been planning to write about it but for one reason or another, I couldn't.

Short version is that I had a great time at the MySQL Camp. I got to meet a lot of new and old friends. It was like a dream come true to hang out with everyone. Very special thanks to everyone I met at the conference as I had some very good discussions. Also thanks to:

Kevin Burton of TailRank for his idea
Jay Pipes for his intense hard work to make this event a big success
Leslie "Hacker Herder" Hawthorn, Mickey, Kynan, Chris and others for their excellent hospitality
Jeremy Cole and …

It seems, people are clammering for a more consolidated help guide for SQL Performance tips.

Jay Pipes at the MySQL Camp ran a session Interactive Top 10 SQL performance Tips. There was plenty of input and discussion, and at the time Sheeri simply typed them into a wiki page for later work.

Well it seems even that rough list is popular at Del.icio.us ranking near the top of the Hot List on the front page. I saw it earlier and it was second or third, but didn’t think of taking a screen shot until now, but it’s still high.

I’d say that we could easily …

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):
…